Payment Go-Live Cutover: Verify the First Live Transaction End to End

Header image: conceptual illustration.

Sandbox testing is complete, but accepting the first live payment is a different decision. Credentials, merchant-account scope, webhook destinations and financial reports may all change at cutover. A test success cannot establish that the live path is correctly connected.

This guide covers the controlled transition and first-live-transaction evidence. Use the pre-launch integration checklist for the broader functional tests; do not replace them with a single live payment.

Freeze the scope of the cutover

Identify the exact merchant account, enabled methods, currencies, deployment and provider API configuration being moved. Confirm that the provider has authorized the intended live use. Technical access to live keys does not itself prove commercial approval or permission for a business category.

Name the person who can enable the path, the observer who will verify it, and the person authorized to stop new initiation. Define the stop conditions before the test: mismatched amounts, wrong merchant account, missing status processing or duplicate financial effects are examples.

Do not include unapproved methods simply because they appeared in a sandbox. Availability and approval must be verified for the actual live account.

Map environment-specific dependencies

List server-side credentials, client publishable configuration where applicable, webhook endpoint and signing/verification configuration, return destinations, scheduled status checks and report access. Record the intended environment of each dependency without copying secret values into a checklist.

Stripe's key documentation explicitly separates sandbox and live objects and explains that webhook signing secrets are distinct from API keys. Changing one API key is therefore not enough to verify the whole integration. SSLCommerz's documentation also provides separate sandbox and live integration context.

Check that a scheduled recovery job has not retained sandbox configuration while the checkout has moved to live. A browser-facing status page and the worker that fulfills the order should read the same intended operation.

Execute only an authorized live pilot

Obtain authorization for the payer, amount, payment method and any planned refund. This is a real financial operation, not a harmless synthetic event. Do not send unsolicited customer tests or use real identity media to exercise an unrelated payment flow.

Use a clearly identified internal pilot order. Record its expected amount and currency before initiation. Complete the provider's supported customer flow, then retrieve the verified result using the live merchant context.

A successful final provider status must match the expected merchant/order reference, amount and currency. Only then should the ordinary idempotent crediting or fulfillment path run. A working return page or an email receipt is not sufficient evidence.

Tracing the pilot from checkout to settlement

Invented example: An authorized merchant tester creates DEMO-LIVE-ORDER for an approved amount and method. The initiation service records a live provider resource. The return page shows awaiting confirmation because the webhook has not yet been processed.

The live webhook passes the correct provider verification and resolves to the pilot order. The worker verifies final success, amount and currency and posts one credit. The status page then reads the same verified record. A repeated notification adds no credit.

Finance verifies that the operation is visible in the appropriate provider transaction or balance report. Later bank settlement is checked according to the provider's actual schedule rather than claimed immediately. If a refund is part of the authorized pilot, its separate operation and final outcome are also reconciled.

Stop new traffic without abandoning old operations

If verification fails, disable new initiation for the affected path using the prepared control. Preserve access to existing operation status, incoming notifications and reconciliation records. Switching every dependency back to sandbox would strand real live transactions.

Investigate account mismatches and missing worker updates before restarting the pilot. An unknown financial outcome must be resolved or escalated; it should not be followed by repeated new live payments to see whether one eventually works.

The payment API overview helps distinguish initiation, notification and ledger boundaries so the stop decision affects the correct stage.

Evidence required before wider rollout

• Correct live merchant context and approved method.
• Environment-specific credentials and webhook verification configured.
• Expected order, amount and currency match the provider result.
• One financial effect despite duplicate notification delivery.
• Customer status reads back from the verified server record.
• Provider reporting shows the same transaction identity.
• Stop control blocks new initiation but preserves existing-operation recovery.
• Any pilot refund or settlement follow-up has an owner.

Go-live sign-off questions

Does a sandbox pass mean the live configuration is approved?

No. It proves only the tested sandbox behavior. Verify account approval and environment-specific dependencies separately.

Should the pilot be marked complete before settlement?

Distinguish integration verification from financial settlement follow-up. Record which evidence is complete and which remains pending instead of merging them into one success label.