KDPika Licensing
Sign inStart freeKeep the license decision close to the protected operation, and keep management credentials on infrastructure you control.
What you will learn
- Choose an enforcement point for four application types.
- Identify the state each integration must persist.
- Find the matching foundation guide and executable example.
Prerequisites
- Read core concepts.
- Choose a runtime from the quickstart.
- Know which resources run on your server and which run on a customer's machine.
Desktop application
Recommended architecture: the application process handles activation and signed validation. Electron uses the main process, not a renderer containing management secrets.
Protect paid exports, batch operations or local premium tools with a valid result and the required entitlement. Do not check once in the activation dialog and forget to gate later actions.
Persist one installation ID, a protected activation token and signed cache. Use configured offline deadlines rather than unconditional network dependence or unlimited offline access.
Trade-off: a local application can be patched. Valuable cloud actions still need authenticated server authorization.
Start with Python, JavaScript or C#; follow normal/offline flows.
SaaS backend
Recommended architecture: authenticate your user, resolve their entitlement on your backend and check access before protected server operations. Your browser UI may display the result but must not be the authority.
Protect API actions, exports and server-owned resources, not just a hidden button. Bind license ownership to your authenticated account using your own server-side mapping.
Use a stable installation identity for the backend deployment or tenant integration policy you intentionally choose. Do not generate a device ID per HTTP request or trust an ID submitted freely by an untrusted browser.
Management keys stay in your backend secret configuration. They create or renew licenses only after your separate sales flow confirms a purchase.
Trade-off: shared/multi-tenant backend identity and concurrency need your own design; there is no built-in end-user login system or floating-seat lease service for your SaaS customers.
Start with PHP or Node.js, then authentication.
CLI or developer tool
Recommended architecture: the tool offers an explicit activate command, checks before licensed actions and offers an explicit deactivate command.
Protect paid commands and online resources; show actionable nonzero exits for invalid licenses. Avoid putting a real key in a command-line argument that can enter shell history or process listings.
Persist the random installation identity and protected token under the current user's application-data directory. Separate state for different products and environments.
Trade-off: headless machines may not have a credential service. Permission-protected files need OS review; an optional keyring backend is not guaranteed to exist.
Start with Python. The cURL check tests transport only, not a secure production client.
Plugin or extension
Recommended architecture: activate the installed plugin through the client flow, and put license-management actions on your own trusted backend. A customer-controlled WordPress/server installation is still distributed software, not your secret vault.
Protect premium plugin operations locally and gate valuable online services on your backend. Browser extensions cannot safely conceal a management key in their bundle.
Persist an installation identity suitable for that installed instance. Document whether a staging copy, migration or reinstall should consume another seat; the server sees the identity supplied by your integration, not an infallible hardware fingerprint.
Trade-off: copied plugin state may carry the same installation identity. KDPika does not automatically detect every cloned host or supply a marketplace fulfilment plugin.
Start with PHP for a PHP plugin, then read device/activation outcomes.
Deployment and sales boundaries
Your app's licensing environment, your sales provider's test mode and your KDPika platform subscription are different concerns. KDPika checkout does not collect money from your software buyers.
Use the go live checklist for all four architectures. Store-specific implementation guides remain separate phase deliverables; this foundation does not claim an installed store integration.
Expected result
You have an enforcement point, a state-storage plan and a clear distinction between application activation and server management.
Common mistakes
- Treating the customer-hosted plugin as your trusted backend.
- Generating a new installation for every SaaS request.
- Protecting only front-end UI while leaving server endpoints unrestricted.
- Treating the CLI cURL smoke check as signature verification.
Security notes
Do not distribute developer API keys. Always guard entitlement access with a valid result. Test actual SDK serialization and cache behaviour before promising offline support in your product.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| SaaS feature works through direct HTTP despite a disabled button | Backend lacks authorization | Gate the protected endpoint on your server |
| Headless CLI cannot unlock keyring | No usable OS credential backend | Review a protected-file strategy or install a suitable supported store |
| Staging copy consumes a seat | It has a different installation identity | Define and communicate your staging/transfer policy |
| Customer expects marketplace auto-fulfilment | No store backend integration was implemented | Connect your confirmed order flow deliberately |
Next steps
Run the quickstart and complete the go live checklist.