KDPika Licensing
The customer portal lets your software customers see their own licenses and release devices they no longer use. It is not your developer dashboard and contains no selling, payments, invoices or payment refunds.
What you will learn
- Share your customer sign-in page from Customer portal settings.
- Use email links or a license key without a separate customer account.
- Manage devices and stuck shared-seat sessions within your product’s removal limit.
- Customize the portal using your existing brand name, logo, accent and support email.
Prerequisites
Create a customer and license in your workspace. The customer email must be correct. Configure your existing email delivery service and ensure its queue is processed by your cron job. A Sandbox license appears only in the Sandbox portal; Live is separate.
Share and sign in
In Customers or Email & notifications, open Manage customer portal. Copy the customer sign-in URL. Live is the default; add ?environment=SANDBOX when testing Sandbox licenses.
The customer enters their email and sees the same response whether or not it matches a customer. If it matches, the queued email contains a single-use link valid for 15 minutes. Opening it shows a confirmation button: email scanners do not consume it simply by visiting. Continuing exchanges it for a private two-hour session, removes the token from the address bar, and prevents the link from being used again. Session inactivity may end access sooner under the platform’s session policy.
A developer-generated link in Customers is also single-use. Its selected expiry can be 15 minutes to seven days; that is the deadline to sign in, not a reusable portal password. Creating another link replaces unused links, but does not invalidate an already signed-in session. Sign out ends the current session.
Customers can also sign in with a license key. That opens only that license, not every license belonging to the email on it. Email sign-in opens that customer’s licenses from the selected publisher and environment. Keys are posted privately, never included in a URL and never shown in full in the portal.
What customers see
- License status and expiry, plan name, masked key and device allowance.
- Effective features: plan features plus license-specific overrides. Disabled overrides stay disabled.
- Machines: name, operating system, app version and last-seen time.
- For usage-credit licenses: current balance and the latest 20 credit changes, without internal notes or request keys. “Returned” means returned usage units, not a payment refund.
- For shared-seat licenses: running app sessions, last check and session expiry. No activation, seat or developer tokens are disclosed.
Self-service actions
Deactivate releases the selected machine, invalidates its activation tokens and ends its running app sessions. The app must activate again before using that license.
End session frees a shared seat for a stuck app without revoking its machine. A running app may request a seat again; this is not a permanent ban. Contact the publisher if a device must be blocked permanently.
Each product defaults to 3 removals per customer in any rolling 30 days. Machine deactivations and ending sessions share that allowance across all that customer’s licenses and portal sessions for the product/environment. Failed or repeated actions do not consume another removal. Developers may set 0–100 in portal settings; 0 requires customers to contact support. A publisher can still manage devices from their own authenticated dashboard.
Your brand
Use Customer portal settings for name, HTTPS logo, accent color and support email; these reuse the existing customer email branding fields. Enable Hide KDPika branding to remove platform branding from portal chrome and portal sign-in emails. The platform domain and platform privacy notice remain identifiable; branding is not a claim of an independent host.
Custom domains are not activated by this release. They require verified DNS ownership, a unique domain-to-workspace registry, shared-host/vhost routing, automatic TLS renewal, host validation and a deliberate secure session-cookie policy. A CNAME alone is not enough; do not point customer domains at the application yet.
Expected result
A customer signs in without registering, sees only their permitted licenses, and manages devices without contacting you for every routine change. They cannot spend/grant credits, change your plans or access any financial functionality in this portal.
Common mistakes
- Sharing a private email link publicly instead of sharing the sign-in page.
- Using a Sandbox link for a Live purchase, or entering a different customer email.
- Treating a license-key login as proof of ownership of every license on that email.
- Expecting an offline app to learn immediately that its machine was revoked: it must reconnect, and existing signed offline policy still applies.
Security notes
Links and portal sessions use cryptographically random secrets stored hashed in their database tables. Sign-in email bodies are encrypted while queued, then cleared by the existing sender on delivery. The bearer may still appear in email systems or your host’s initial access log; configure access-log redaction/retention at the host. The app sends no-referrer/no-store/noindex headers and removes the bearer from subsequent URLs. Confirmation and actions require CSRF protection. Email/IP rate limits apply equally to known and unknown emails. This reduces practical enumeration risk but cannot promise identical execution time in all hosting conditions.
Every action rechecks tenant, customer, optional license scope and environment on the server. Removal quota checks and changes use row locks and one transaction. Successful login and actions are recorded in the existing audit log without secrets. Ed25519 signing and SDK behavior are unchanged by this phase.
No standalone offline license-file download is added: the existing offline grant is bound to an activated installation and delivered by the signed SDK flow. Exporting another generic key would bypass that binding.
Troubleshooting
| Problem | What to do |
|---|---|
| No email | Check the entered email/environment, spam folder and publisher email queue; wait before resending |
| Link used or expired | Request a new one; the same link cannot create another session |
| Removal limit reached | Contact the publisher; the allowance is shared across the product’s licenses |
| Session reappears | The app is still running and requested a seat again; close it or deactivate its machine |
| Logo missing | Use a reachable HTTPS image; private or blocked external image URLs cannot be displayed |
Next steps
Test with separate customers and both environments before sharing your public sign-in URL. Review your product’s device allowance and offline policy.