Go live checklist

Move to Live only after the actual application, its failure paths and its support process have been tested.

What you will learn

• Review production readiness without confusing it with a successful demo.
• Plan safe credentials, customer support and operations.
• Identify known defects or missing operational evidence that block your own release.

Prerequisites

• Complete the Sandbox quickstart.
• Read integration limitations.
• Have eligible paid Live access and control of your application's release process.

Credentials and environment

1. Confirm the paid platform entitlement and Live availability in Billing.
2. Issue Live customer licenses deliberately; do not reuse Sandbox records.
3. Create separate minimum-scope Live server keys only where management is needed.
4. Put public App ID and explicit LIVE selection in the app configuration.
5. Remove Sandbox sample keys, debug dumps and developer API keys from distributed artifacts.
6. Rehearse immediate key replacement and revocation without assuming an overlap window.

Detail: environments and authentication.

Expected result: each credential has an owner and a specific product, environment and consumer.

Signed decisions and application enforcement

1. Require valid or Valid before every feature decision.
2. Test a real signed response for your product metadata, numeric features and customer text.
3. Test persisted cache round trips in the actual SDK release.
4. Verify product, environment and installation binding, expiry and signed deadlines.
5. Keep protected server actions authorized on your backend.
6. Record a signing-key rollout plan if you pin a public verification key.

Detail: activation flow and signature/cache limitations.

Expected result: tampered, wrong-installation and invalid license results do not unlock access.

Known JavaScript integral-float and C# cache limitations remain release risks. Do not mark this checklist passed merely because the narrow demonstration data works.

Failure paths and end-user UX

1. Test invalid key, wrong supplied email, wrong environment and installation mismatch.
2. Test device exhaustion and cumulative activation exhaustion separately.
3. Test expired, suspended and revoked licenses.
4. Test timeout, unavailable server, missing cache, expired grace and clock rollback.
5. Test deactivation and a deliberate reinstall/transfer.
6. Use plain messages that say what the customer can do without inventing a payment cause.

Detail: flow outcomes and lifecycle.

Expected result: users can retry a network problem or contact the publisher; confirmed invalidation does not receive outage fallback.

Offline policy and storage

1. Choose validation interval and offline grace appropriate to your risk.
2. Explain offline deadlines to your customers before purchase.
3. Test the actual packaged app on Windows, macOS and Linux versions you support.
4. Review token storage, file permissions and optional keyring behaviour.
5. Decide recovery behaviour for lost or copied application state.

Detail: offline flow and local state.

Expected result: bounded offline access works as intended without claiming instantaneous disconnected revocation.

Webhook operations

1. Use an HTTPS endpoint on your backend with the correct environment.
2. Store its signing secret privately and verify signatures and timestamp tolerance.
3. Deduplicate repeated event handling and tolerate ordering differences.
4. Monitor delivery failures and exhausted retries.
5. Rehearse secret replacement; current queued attempts use the current endpoint secret.

Detail: webhook summary and current operational limitations.

Expected result: missing webhooks do not determine whether a license is valid. Follow the complete event/security reference when it is published; this checklist is not a replacement verifier implementation.

Monitoring, limits and backup responsibility

1. Monitor API and audit logs, request IDs and webhook delivery history.
2. Review plan creation limits and current usage before a sales launch.
3. Check platform status and handle unavailable network requests in your app.
4. Protect backup copies of your own server credentials under your recovery policy; never ask customers to back up KDPika private signing keys.
5. Preserve nonsecret mappings between your orders, customers and issued license IDs.
6. Confirm scheduler, backup and restore operations for systems you operate rather than assuming an untested RPO or RTO.

Detail: platform versus product capacity and network outcomes.

Expected result: operational failures can be diagnosed without exposing secrets. The same-host status page is not an independent monitor or an SLA.

Sales, privacy and customer support

1. Confirm purchases in your own backend before issuing software licenses.
2. Document your refund, renewal, transfer and lost-key policies.
3. Give customers a publisher support channel and a recovery procedure.
4. Minimise customer information sent into metadata and labels.
5. Review your privacy notice, retention and the platform's processing terms.
6. Confirm the remaining hosting/provider/legal facts relevant to your own obligations.

Detail: sales boundaries, use cases, privacy and DPA.

Expected result: software buyers know whom to contact; KDPika platform billing is not confused with your product sales.

Expected result

Each applicable check has an actual test or operational owner. Unresolved security/compatibility risks are documented and addressed before your application is declared production-ready.

Common mistakes

• Checking only a successful activation on one development machine.
• Assuming a demo certifies every OS credential backend.
• Treating an advisory monthly API allowance as a hard block.
• Claiming compliance, response-time guarantees or uptime without confirmed evidence.

Security notes

Do not disable verification to pass a release test. Fully controlled customer machines can patch local code. No checklist is an independent security audit or universal legal certification.

Troubleshooting

Next steps

Review use-case trade-offs and resolve any blocked check with your engineering and support owners.

Related

• Quickstart
• Authentication
• Current integration limitations