A pre-launch checklist for a money-movement feature is not a formality you run the day before you ship. It is the point where every earlier module gets verified against production reality instead of a staging environment that lies to you. The unhappy paths you scoped, the ledger you designed, the idempotency keys you wired, the reconciliation job you built: this is where you confirm they actually hold when the first real dollar moves.
The discipline here is binary. A checklist item is green or it is not. "Mostly works" is red. We treat a money feature as blocked until every line below is verifiably true, because the failure mode for payments is not a broken page, it is a customer charged twice or a payout that never lands.
Separate the environment before anything else
The most common launch-day failure has nothing to do with your logic. It is a configuration mismatch between test and live credentials. Every Stripe API request runs in either a sandbox or live mode, each mode has its own API keys, and objects created in one mode are not accessible in the other. Products, coupons, and prices built in a sandbox do not exist in live mode.
Webhooks are where this bites hardest. When you reuse the same endpoint URL, the signing secret differs between test and live. If production ships with the test webhook secret in place, every signature verification fails silently, the app ignores the events, and fulfillment stops with no error in your logs.
What to verify
- Live API keys are in production secrets, test keys are nowhere near it, and a single grep confirms no test key string ships in the build.
- The live webhook endpoint exists in the dashboard, points at the production URL, and your handler reads the live signing secret, not the test one.
- You have sent one real event through the live endpoint and watched it verify, parse, and complete the downstream action end to end.
Prove the ledger stays correct under load
Module 4 built a ledger that balances. The checklist confirms it still balances when concurrent writes hit it. Run a load test that fires overlapping operations against the same account and assert that debits and credits sum to zero across every account at the end.
Confirm that your idempotency keys actually deduplicate. Replay the same charge request five times with the same key and verify exactly one ledger entry and one external charge result. Then replay it after a simulated process crash mid-write, because that is the case that produces duplicates in the wild.
Here is a worked example from one launch. We replayed a $4,200 transfer request twice with the same idempotency key against the live-shaped staging ledger. The first call wrote the entry; the second returned the stored result without writing a second one. We then dropped the connection after the debit but before the credit and confirmed the retry completed the credit rather than re-running the debit. Only after both passed did that line go green.
Confirm reconciliation and the money path
Reconciliation is not a back-office nicety, it is the only thing that tells you the truth about what moved. Before launch, run your reconciliation job against a day of real-shaped test settlement data and confirm it flags a deliberately injected mismatch. A reconciler that never reports a break has not been proven to work.
Verify settlement timing assumptions against the processor's actual schedule, not the number you remember. Confirm where funds land, when they become available, and what your system shows the customer in the gap between authorization and settlement.
Clear the compliance gates
Compliance is a hard gate, not a stretch goal. If the feature touches cardholder data, confirm the PCI DSS v4 requirements that became mandatory on March 31, 2025 are in place, including multi-factor authentication for all access to the cardholder data environment, a minimum twelve-character password length (eight where the system cannot support twelve), and encryption at the file, column, or field level rather than disk-level encryption, which on non-removable media no longer qualifies on its own for rendering the primary account number unreadable.
Confirm with your compliance owner in writing that the feature is cleared. A verbal "should be fine" is a red line on this checklist.
Compliance line items
- The data you store is the minimum needed, and you are not persisting full card numbers you have no reason to hold.
- Audit logging captures who moved money, when, and through which path, in a form you can hand to an investigator.
- Any new third-party processor or data flow has been reviewed against your existing scope.
Wire observability and a tested rollback
You cannot operate what you cannot see. Confirm that authorization rate, decline rate, latency, and webhook delivery success are on a dashboard with alerts set before launch, not after the first incident. A sudden decline-rate spike should page someone, because it usually means a config or routing break, not customer behavior.
Then prove the rollback. A feature flag you have never flipped under load is not a rollback plan. Toggle the kill switch in staging, confirm in-flight transactions settle or fail cleanly rather than hanging half-done, and confirm no money is left in an indeterminate state. Decide in advance what "abort" does to a payment that is already authorized but not captured.
Launch posture
Ship behind a flag, to a small cohort first, with someone watching the dashboard live. The point of a staged rollout is to catch the failure that only appears with real money and real volume while the blast radius is still ten customers, not ten thousand.
The closing takeaway
The checklist is green only when every line is independently verifiable by someone other than the engineer who wrote it. Environment isolation confirmed, ledger balanced under concurrency, idempotency proven against a crash, reconciliation catching a real break, compliance signed off, observability live, rollback tested. If any one of those is amber, the feature does not move money yet. The cost of holding a launch one more day is a day. The cost of shipping a payments bug is a refund queue, a chargeback wave, and a trust problem you cannot patch.