03.05 · Walkthrough
Test Mode Is a Different Planet
Exercise the whole money path against a sandbox, including replayed webhooks, and list what is still untested the moment you switch on live keys.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Payments lesson by lesson; 26 of 35 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
Test mode proves your payment integration can complete a sandbox flow, not that live money is safe. Treat sandbox and production as separate systems: run checkout end to end, verify and replay webhooks, confirm idempotent order updates, then explicitly list the live-only risks still untested.
What this lesson answers
- what does payment test mode actually prove
- how to test payment webhooks safely
- what remains untested after sandbox checkout
Notes
Payment test mode is not a small flag on production; treat it as a separate planet with separate credentials, objects, dashboards, event history, and failure modes. A successful sandbox checkout proves that your code can talk to the provider, create a payment-like object, receive a payment-like event, and update your database, but it does not prove that live money will behave identically.
The concrete mental model is an end-to-end rehearsal. Start from your app, create a checkout or payment session using test keys, complete it with provider-supplied test cards or payment methods, receive the…
References
Common questions
- Is a successful test mode payment enough before going live?
- No. It shows your application can create a provider object, receive a sandbox event, and update your own state. Live processing still adds real banks, risk checks, production secrets, live webhook routing, operational permissions, and real customer behaviour. Those need a separate go-live checklist.
- Why should payment webhooks be replayed in testing?
- Webhook replay proves the handler is idempotent. Providers may send the same event more than once, and your code must not ship twice, send duplicate emails, or corrupt the order. A safe handler should recognise that the order is already paid and leave the system consistent.
- Should checkout success in the browser mark an order as paid?
- No. The browser return means the customer completed the front-end path, not necessarily that the provider confirmed the payment. The durable state change should come from a verified webhook, especially for payment methods that complete asynchronously or involve extra provider-side checks.
Short definition: what is Test Mode Is a Different Planet?