Going live checklist
Everything to flip, verify, and harden before you swap your test keys for live keys.
When sandbox testing is complete, this is the runbook for going live. Work top to bottom. Don't skip the verification steps — each one represents a class of mistake we've seen real merchants make.
1. Credentials
- Live keys (
pk_live_…/sk_live_…) issued by your account manager - Secret key stored in your secrets manager — never in source control
- Test keys removed from production config (no fallback to sandbox)
- Old test-mode webhook URL retired or pointed at a no-op handler
2. Webhook endpoint
- Live webhook URL registered with your account manager
- Endpoint is HTTPS, public, and responds inside 10 seconds
- Signature verification implemented with
crypto.timingSafeEqual— see Verify webhook signatures - Endpoint rejects mismatched
environmentfield (live handler refuses"test"events) - Deduplication on
eventIdis in place — handlers are idempotent - Handler returns 2xx promptly; heavy processing happens asynchronously
3. Idempotency
- Every
POST /payments,POST /subscriptions, andPOST /refundincludes anexternalIdyou control -
externalIdis unique per intent — orders, invoices, refund batches - No accidental reuse across customers or environments
4. Final dress rehearsal
Before flipping traffic:
- Run one live charge with a real card you control — confirm
payment.succeeded - Verify funds appear in your settlement account
- Refund the same charge — confirm
payment.refundedand money returns - Subscribe yourself to a recurring plan — confirm the renewal cron fires
- Cancel the subscription — confirm
subscription.cancelled
Don't run end-to-end tests with live charges on real customer cards
The dress rehearsal uses a card you own. Once that passes, switch traffic for real customers. Never use someone else's card to test your integration in live mode.
What to monitor in the first week
- Webhook delivery success rate — should be near 100%; we retry, but persistent failures need investigation
payment.failedrate by error code — sudden spikes usually mean a config drift- Subscription churn at the
past_due → cancelledboundary — early signal of dunning issues requestIdcorrelation between application errors and MintCash failures
If anything looks off, your support channel goes both ways. We see your traffic too — flag anything anomalous and we'll dig in together.
Issue a refund
Refund a successful payment in full or in part. Multiple partial refunds are allowed up to the original amount.
API reference
REST endpoints for payments, subscriptions, refunds, and API key management. Every endpoint is interactive — fill in your test key and send real requests from the page.