Payments Go-Live Checklist: From Test Mode to Production Without Costly Mistakes

You built the checkout, tested it with the test cards, and everything works perfectly. Then you flip the "go live" switch, and that's where the real problems start: the payment goes through but the money never arrives, the webhook doesn't confirm the order, or the customer gets charged twice. In test mode none of this hurts. In production, every mistake is money lost or a customer upset.

The difference between test and live isn't a simple toggle. There are separate keys, an account that must be fully verified, separate webhooks, and a pile of legal details that in the EU are mandatory. Below is the checklist we run before every payments launch, in the order that matters. This isn't theory: these are exactly the things that break most often.

1. Live keys, activated account, nothing test left in the code

The first trap: the keys. In Stripe (and nearly every processor) you have a set of test keys and a set of live keys, completely separate. Data doesn't cross between them — orders, customers and subscriptions from test don't exist in live.

Check that:

• The live key is in environment variables, NOT hardcoded and NOT pushed to Git.
• You replaced it everywhere: frontend (public key), backend (secret key), and any connected service.
• The account is fully activated: business details, bank account for payouts, identity verification (KYC) complete. Without it, you can collect but not withdraw.
• You removed test buttons, products and prices from the live page.

A single forgotten `sk_test_` means payments that look like they work but collect nothing real.

2. Webhooks: where most payments break

The most common go-live mistake: the test webhook stays, while the production one is missing or has the wrong secret. The result is brutal — the customer pays, the money reaches the processor, but your site never finds out, so the order stays unconfirmed.

Check that:

• You created a SEPARATE webhook endpoint for live mode, with its own signing secret.
• You verify the signature of every event before processing it (otherwise anyone can fake a payment to you).
• You handle events idempotently: the same event may arrive twice, and your code must not fulfil the order twice.
• You rely on the webhook for final confirmation, not the browser redirect — the user can close the tab before returning.

Test it with a real payment, not just the simulator.

3. Amounts, currency and tax: mistakes that cost exact money

Most processors work in the currency's smallest unit. 100 dollars isn't sent as "100" but as 10000 (cents). It's a classic mistake to display it correctly on the page but send the amount multiplied or divided wrong — and the customer is the one who tells you they were charged the wrong amount.

Check that:

• Amounts are calculated on the server, never taken from the price sent by the browser (anyone can tamper with that).
• Currency is correct and consistent everywhere.
• Tax is included and clearly shown, and the final checkout price matches the product page.
• You use idempotency keys when creating the payment, so a double-click doesn't create two charges.

A test transaction with a real amount instantly shows whether the numbers line up.

4. 3D Secure, SCA and what happens when a payment fails

In the EU, strong authentication (SCA / 3D Secure) is mandatory for most card payments. In test mode, test cards often pass without the bank's confirmation step. In production, the real customer gets an SMS or a banking-app notification — and if your flow doesn't handle that step, the payment appears to "freeze".

Check that:

• Checkout supports the 3D Secure authentication step and waits for its result.
• You have clear failure states: card declined, insufficient funds, abandoned authentication — with messages the customer understands.
• The customer can retry without losing their cart.
• Refunds work: test one for real, so you know what it looks like when you actually need it.

A checkout without error states loses customers silently.

5. The legal side: without it, the payment isn't complete

A checkout that works technically but doesn't have its paperwork in place exposes you to complaints and fines. Online commerce has clear requirements.

Check that:

• Terms and Conditions, Privacy Policy (GDPR) and Return Policy are accessible from checkout.
• Prices are shown with tax included.
• Company details are visible (name, registration number, address, contact).
• Where required, the link to the EU online dispute resolution platform and consumer-protection info are present.
• An invoice is issued automatically after payment — connect your checkout to an invoicing system from the start rather than patching it later.

These feel like bureaucracy until the first complaint. Solve them once, properly, and you stop thinking about them.

6. The final test: a real transaction, then a refund

The last step before you call yourself live: make a real payment yourself, with your own card, for a small amount. It's the only way to see the whole chain working together — checkout, 3D Secure, webhook, order confirmation, email, invoice, and the money appearing in your payout account.

Then refund that same transaction and confirm the return goes through cleanly. If all of that lines up once, you're ready.

At MPO Web Studio we build sites with integrated payments remotely, nationwide, and we run exactly this go-live path together with the client — with a pre-built demo ready before you pay anything. If you'd like us to run this checklist on your site before launch, message us on WhatsApp and we'll walk through it step by step.