Mintcash
Guides

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 environment field (live handler refuses "test" events)
  • Deduplication on eventId is in place — handlers are idempotent
  • Handler returns 2xx promptly; heavy processing happens asynchronously

3. Idempotency

  • Every POST /payments, POST /subscriptions, and POST /refund includes an externalId you control
  • externalId is 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.refunded and 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.failed rate by error code — sudden spikes usually mean a config drift
  • Subscription churn at the past_due → cancelled boundary — early signal of dunning issues
  • requestId correlation 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.