Payments
Real money, irreversible — where a bug costs customers and trust.
Payments are the one place a bug doesn't just throw an error — it double-charges a customer or silently loses revenue. It's also the clearest line between what AI can scaffold and what you must own: the SDK wiring is free, but every decision that moves money is yours.
Ready to test yourself on this kind of call?
Practice the on-call scenario →What you own
- ▪The idempotency strategy
- ▪The reconciliation logic
- ▪How failures and refunds are handled
- ▪Every decision that moves money
▸Hand to AI (4)
- Integration boilerplate and SDK wiring
- Webhook handler scaffolding
- Test fixtures and mock events
- A first draft of the orders/subscriptions data model
What to learn (the durable stuff)
Idempotency
making a retry safe so a network blip can't double-charge (idempotency keys).
Webhooks vs the redirect
never fulfil on the browser redirect; confirm server-side from the webhook, and verify its signature.
Reconciliation
matching your records against the provider's so you catch what fell through the cracks.
The unhappy paths
failures, refunds, disputes, chargebacks are most of the real work.
Fees, payout timing, and 'merchant of record' (who handles your sales tax).
PCI scope
never let raw card numbers touch your server; use the provider's hosted fields.
Current tools (these change fast)
Practice this scenario
You're on call. Revenue dropped ~20% overnight with no deploy. You have webhook logs, Stripe events, and your DB order records. Walk through how you'd find the root cause — what do you check first, and why?
Practice the on-call scenario →