Sandbox purchases produce real events and webhooks, flagged
"environment": "Sandbox", so you can exercise everything end to end. Apple
runs sandbox subscriptions on an accelerated clock (a month renews in minutes),
which is the fastest way to watch a full renewal lifecycle.
Testing
Test mode vs live, store sandbox accounts, seeded data, and a go-live checklist.
CashSDK gives you a full test environment that mirrors production: separate keys, separate data, and the same APIs, so you can validate the entire purchase flow before a single real charge.
Sandbox vs Production#
There are no separate test keys. An app has one publishable key and one secret key, and they serve both environments. The store decides which one a purchase belongs to:
| How the build runs | Store environment |
|---|---|
| From Xcode, or installed via TestFlight | Apple Sandbox |
| Installed from the App Store | Production |
| Google Play internal/closed testing track with a licence tester | Play test purchase |
CashSDK reads the environment out of the store's own signed payload, so a client cannot spoof it, and entitlements are resolved and cached per environment, a Sandbox purchase never grants Production access to the same user, and sandbox revenue never mixes into your production numbers.
Configure the SDK exactly the same way in both cases:
swift
CashSDK.configure(publishableKey: "csk_pk_…")
Store sandbox accounts#
Native store purchases in test mode require a store sandbox tester:
- Apple: create a Sandbox Apple Account in App Store Connect (Users and Access → Sandbox) and sign into it on the device under Settings → Developer.
- Google: add the tester's Google account to your app's license testers in the Play Console, and use an internal testing track.
Sandbox subscriptions renew on an accelerated clock (minutes, not months), so you can watch renewals, expirations, and grace periods play out quickly.
Seeded sandbox data#
Test mode comes pre-populated with real seeded rows (apps, a product catalog,
paywalls, customers, and transactions) so the dashboard, APIs, and analytics
are fully populated on day one. It's real data in your database, not mocks, so
GET /v1/apps/{app}/customers and friends return exactly what production would.
Verify your setup#
1
Run the doctor
The CLI checks keys, store credentials, webhook endpoints, and catalog wiring in one pass.
bash
cashsdk doctor
2
Review the checklist
See exactly what's left before go-live, live-computed from your workspace.
bash
cashsdk checklist
The same data is available at GET /v1/apps/{app}/setup/checklist.
3
Request an Apple test notification
Confirm your App Store Server Notification pipeline end to end with the MCP
request_apple_test_notification tool. Apple sends a test notification to
your instance, which verifies it and emits the corresponding webhook.
text
request_apple_test_notification(app="my-app")
4
Fire a test webhook
Use send_test_webhook (or the dashboard) to confirm your endpoint verifies
the CashSDK-Signature and handles the event. See Webhooks.
Go-live checklist#
1
Swap to live keys
Replace csk_pk_… with csk_pk_… in your app and csk_sk_… (live) on
your backend, sourced from environment variables, never hard-coded.
2
Confirm store credentials
Production App Store Connect and Google Play credentials are connected and
validated (cashsdk doctor passes).
3
Point store notifications at production
App Store Server Notifications and Google Play RTDN target your live instance, and your webhook endpoint is registered and verifying signatures.
4
Smoke-test a real purchase
Buy and refund once in production, confirm the entitlement grants and revokes, and check the event lands on your webhook.