Integration Readiness (Pre-Prod)

Pre-production checks for payment confirm, routing, sandbox, webhooks, trace, and dashboard.

Before going live, filling this checklist in sandbox is not enough; you must actually exercise each item. A single successful payment does not mean you are ready.

In particular, validate the split between create and confirm, multiple charge attempts, webhook retries, and sandbox vs production credential separation together.

Environment separation

Check	Expected state
Sandbox account	Sandbox accounts linked to production accounts are separated in the dashboard.
Sandbox mode	Requests sent with a test account or sandbox context must not move real money.
Production secrets	API keys, provider credentials, and webhook secrets stay on the server-side boundary.
Test data	Sandbox cards, issuers, and decline scenarios must not mix with production data.

Sandbox is not a real financial network

Sandbox is for testing lifecycle and provider behavior before production. It does not produce real money movement, real issuer connectivity, or production authorization guarantees.

Payment and confirm contract

Before production, exercise at least these flows end to end:

Create a payment, then confirm it.
Send new card data with payment_method.
Confirm with a saved payment method reference.
After confirm, validate payment.status, confirmResult.ok, and adapter latestResult.kind separately.
Interpret payment status and charge attempt outcome separately.
If you use Checkout Session, validate token-based session and return/cancel behavior.

Confirm is the step that moves the payment record into provider execution. Creating a payment alone does not mean a provider call or a financial outcome.

Routing and provider readiness

On confirm, payment method, provider candidates, and a routing plan are formed; the dashboard should show plan + charges together.

Check	Why it matters
Provider config selection	Without a suitable provider/config for the payment method and amount/currency, confirm fails.
Routing strategy input	When routing with a single config or provider identifier, verify candidates are chosen correctly.
Fallback behavior	Account settings and the eligible config pool should produce the expected fallback behavior.
Routing plan trace	Routing plan and charge attempt relationship should be readable in the dashboard.

3DS, decline, and resume behavior

Pre-prod tests must not cover success only:

Is the REQUIRES_ACTION and paymentNextAction.url flow handled by your frontend or hosted checkout?
After resume/callback, is the final payment outcome verified on the backend or via webhook?
On hard decline, does the user get asked for a new payment method?
On soft decline or provider unavailable, is retry/fallback behavior controlled?
After provider timeout, can you query status and track events for the same payment?

Webhook and event handling

Webhook delivery can be delayed or repeated; the merchant handler must not process the same event twice.

Minimum checks:

Webhook endpoint verification is complete.
Duplicate events do not cause double processing.
Payment state is closed from backend/API/event verification, not from frontend redirect alone.
Event payload exposes correlation fields such as payment_id, charge_id, routing_plan_id, request_id, and trace_id.
If webhook delivery is delayed, manual review via dashboard/payment detail is possible.

Dashboard smoke test

Before production, for one sandbox payment verify in the dashboard:

Payment status on the transaction detail screen is correct.
Charge list shows the provider attempt.
Routing card shows plan and current index.
Event list shows payment lifecycle events.
Event detail correlates request/trace fields.
Webhook portal access opens with correct permissions and account context.
Switching from sandbox account to production account is clearly separated.

Data security

PAN and CVV must not be written to production logs.
CVV must not be stored; vault/saved-card flows should respect this boundary for CVV verification behavior.
Provider credentials, API keys, webhook secrets, and signature material must not appear raw in docs, logs, or dashboard payloads.
Raw provider payload vs normalized result should be clear inside the team.
Request/trace ID must not be used like a security token.

Pre-prod decision table

Area	Minimum decision before go-live
Payment lifecycle	Application state map ready for create, confirm, requires_action, success, declined, and refund/cancel scenarios.
Charge model	Team accepts that one payment can produce multiple charge attempts.
Routing	Provider/config candidates, fallback expectations, and error cases validated in sandbox.
Webhook	Event handler is idempotent and safe under retry and delay.
Dashboard	Support and engineering can investigate with payment ID, charge ID, events, and trace.
Sandbox/production	Test data and production credential boundaries are separate.

Critical note

A redirect/return URL result alone does not mean payment success. Use server-side payment record, API query, or event/webhook verification for the final decision.

Integration Readiness (Pre-Prod)

On this page