KDPika Licensing
Sign inStart freeWhat you will do
Exercise negative cases before customers rely on your integration.
Use Sandbox only. This is a checklist for your implementation, not permission to test attacks on other systems.
- Run the Stage 7 file with activate. Confirm one active device.
- Run validate, then check after restarting the process. Confirm the same identity/seat.
- Activate on a second private state directory. With Max devices 2, a third installation must return MAX_DEVICES_REACHED.
- Run deactivate on one installation. A replacement activation should now fit.
- In [Licenses](/docs/v1/start/glossary#license) → Manage, choose Suspend. A forced online validate must deny. Restore allows a new activation; it does not revive the old revoked token. Run activate again before expecting validation to succeed.
- Create a separate test license, choose Revoke and verify denial. Revocation is not a temporary support toggle.
- Test a short-duration/expired license. Do not alter the server clock or production database to fake this result.
- Test supported renewal through the documented backend/store workflow, with a confirmed paid period; it must not duplicate the license. Renew extends the license, not the token's original lifetime. Validate online to obtain the updated signed decision; activate again if the existing token has expired or was revoked.
- Disconnect the network; test valid, missing, corrupted and expired cache states.
- Modify a signed payload in an isolated verifier test. The verifier must deny it.
- Test wrong email, App ID and environment. Cross-environment access must fail.
- Follow your selected store's duplicate, failure, cancellation and refund checklist.
Python
Use the exact same file and state directory for a lifecycle:
.venv/bin/python license-check.py activate
.venv/bin/python license-check.py validate
.venv/bin/python license-check.py check
.venv/bin/python license-check.py deactivate
Activation/validation success prints Sandbox license verified.; deactivation prints Device released. A failure exits nonzero and must not unlock your software.
JavaScript / Node.js
Use the exact same file and state directory for a lifecycle:
node license-check.mjs activate
node license-check.mjs validate
node license-check.mjs check
node license-check.mjs deactivate
Activation/validation success prints Sandbox license verified.; deactivation prints Device released. A failure exits nonzero and must not unlock your software.
PHP
Use the exact same file and state directory for a lifecycle:
php license-check.php activate
php license-check.php validate
php license-check.php check
php license-check.php deactivate
Activation/validation success prints Sandbox license verified.; deactivation prints Device released. A failure exits nonzero and must not unlock your software.
C# / .NET
Use the exact same file and state directory for a lifecycle:
dotnet run --project Guide.csproj -- activate
dotnet run --project Guide.csproj -- validate
dotnet run --project Guide.csproj -- check
dotnet run --project Guide.csproj -- deactivate
Activation/validation success prints Sandbox license verified.; deactivation prints Device released. A failure exits nonzero and must not unlock your software.
cURL / other language
Use the same activate → validate → deactivate sequence in your real REST client project and its signature verifier. Exercise every negative case above; a cURL HTTP response alone is not a passing access check.
Expected result
Your test notes show both successful access and deliberate denials, without real charges or leaked tokens.
If it does not work
Stop at the first unsafe result. Keep the application locked, record a safe request ID and contact support. Do not “fix” a negative test by removing its signature or entitlement guard.
Stage checklist
- All lifecycle, device, state, network and signature cases pass for my runtime.
- I tested the non-programmer delivery route if I use one.
Next steps
Continue to Stage 14: Go live safely
You are here: Stage 13 of 14.