High-Risk Payment Gateway Launch Checklist: 50 Tests Before You Send Traffic

1–5: verify commercial and account configuration

Before testing code, verify that the merchant account contains the correct business name, contact email, fee policy, payout wallet, settlement asset, network and enabled routes. A technically perfect checkout can still fail if the wallet is configured for the wrong network or a payment method has a minimum amount above the store’s normal order value.

Write down the expected behavior for every enabled route. Which countries are supported? Which currencies are presented? Can the customer pay by card, bank or local method? Can customer verification occur? Is the route direct or redirected? The launch team must know what “working” looks like before it can judge a test.

1. Confirm merchant account status and dashboard access
2. Confirm payout wallet ownership
3. Confirm settlement token and network
4. Confirm fee allocation mode
5. Confirm enabled payment routes and amount limits

6–10: session creation and order identity

Every payment attempt should start with a unique merchant order reference and a platform session identifier. The amount and currency must come from the server-side order, not from editable browser fields. Store the customer email only when required and handle it according to the site’s privacy policy. Return and webhook URLs must point to the correct live domain.

Test rejected session requests as carefully as successful ones. Missing amount, unsupported currency, invalid callback URL and duplicate order references should produce controlled errors. The customer should never see raw stack traces, provider secrets or internal SQL messages.

1. Create a normal session from a real order
2. Reject zero or negative amounts
3. Reject unsupported currency values
4. Handle duplicate order references safely
5. Store session ID and order ID together

11–15: hosted checkout and redirect behavior

The customer must understand that the next screen belongs to a payment partner. Test the visible payment label, fee disclosure, provider transition and return path. Open the checkout in a clean browser without admin cookies. Repeat on mobile data because network changes and in-app browsers can expose redirect problems that desktop testing misses.

A redirect should never contain secrets. Query parameters may include amount, currency or a protected reference, but private API keys and raw wallet secrets must remain server-side. Confirm that copied or expired checkout URLs do not create new valid payments indefinitely.

1. Open hosted checkout from desktop
2. Open hosted checkout from mobile
3. Test browser back navigation
4. Test cancellation and store return
5. Test copied, expired and reused checkout URLs

16–20: customer verification and provider outcomes

Customer verification is controlled by the selected provider and can depend on country, amount, payment method and risk signals. The merchant should not promise a verification-free experience unless the live route genuinely provides it for that case. Test the messages shown when verification is required, abandoned or rejected.

A provider decline must return the customer to a useful state. The store should explain whether another method can be tried and whether the original attempt remains pending. Avoid encouraging repeated charges while the first attempt is unresolved.

1. Complete a payment without additional verification where available
2. Observe a verification-required flow
3. Cancel during provider verification
4. Test provider decline handling
5. Test a method unavailable for the customer country

21–25: payment status as a state machine

Define allowed statuses and transitions before launch. A typical flow begins with created or pending, then moves to paid, failed, expired or cancelled. Some providers may report processing before final completion. Paid should be terminal for fulfillment, while a late callback may move an expired-looking external attempt into a paid state only after verified evidence.

The store must not let the browser choose the status. A success return page can display “checking payment” while the server queries the platform. Refreshing the page should not repeat fulfillment. Test each transition and record which system is the source of truth.

1. Keep new orders pending
2. Confirm paid only from server evidence
3. Handle failed as a terminal attempt
4. Expire abandoned sessions
5. Prevent paid orders from returning to pending

26–30: webhook safety and reconciliation

Webhooks should be authenticated, idempotent and logged. Providers retry callbacks, so the same paid event may arrive several times. The handler must recognize the existing event and avoid duplicate emails, license delivery or stock changes. It should also reject invalid signatures and unknown order references.

A reconciliation job is required because callbacks can be delayed or temporarily fail. The job should query unresolved sessions, compare current platform status and update the store safely. Test delayed callbacks and reconciliation together; otherwise the two mechanisms may race and create contradictory logs.

1. Accept a valid signed webhook
2. Reject an invalid signature
3. Process the same paid event twice without duplicate fulfillment
4. Recover a missed callback through reconciliation
5. Log every status-changing event with timestamp and reference

31–35: WooCommerce or store fulfillment

Map platform statuses to store order statuses deliberately. Pending payment should remain unpaid. Paid should move to processing or completed according to product type. Failed, cancelled and expired attempts should not reduce stock twice or trigger customer delivery. Digital access must be linked to verified payment completion.

Test manual changes as well. Support staff may mark an order paid in the store while the platform remains pending. Decide whether manual overrides are allowed, who can perform them and what evidence must be recorded. An undocumented override destroys reconciliation accuracy.

1. Map paid to the correct store status
2. Do not fulfill from the return URL
3. Test digital delivery once only
4. Restore stock correctly after failed attempts
5. Record and restrict manual payment overrides

36–40: fees, totals and customer receipts

The customer, merchant dashboard and order receipt should agree on the product amount, fee and final total. Test the three fee modes if the platform supports customer-paid, split and merchant-paid allocation. Rounding becomes visible on low-value orders and across currency conversions, so test amounts with cents rather than only round numbers.

The merchant’s expected settlement may differ from the customer total because of fee allocation and provider costs. The dashboard should make the relationship understandable. Support agents need a standard explanation so they do not promise that every number visible to the customer will equal the wallet receipt exactly.

1. Test customer-paid fee calculation
2. Test split fee calculation
3. Test merchant-paid fee calculation
4. Test decimal rounding and minimum amounts
5. Confirm receipt and dashboard totals are understandable

41–45: wallet and settlement validation

Complete at least one small live settlement to the configured wallet. Confirm the exact chain, token contract where applicable, amount, transaction hash and wallet visibility. Native network balance and token balance are separate. A wallet can show enough USDC while lacking the native asset required for later outgoing transfers.

Test how the platform reports settlement pending, completed and failed. Store the payout transaction hash or equivalent evidence. If settlement is batched or delayed, document the expected timing and teach support not to confuse customer payment confirmation with merchant wallet arrival.

1. Verify the receiving address
2. Confirm token and network match
3. Record a live payout transaction hash
4. Check native gas balance separately
5. Reconcile platform settlement with wallet receipt

46–50: security, support and launch controls

Rotate any secret exposed during development, restrict admin access and make sure logs do not contain card data, private keys or seed phrases. Test the public site with normal security controls enabled. A launch that works only after disabling the firewall or WAF is not ready.

Prepare support scripts for pending, failed, expired and paid-but-not-reflected cases. Set a launch traffic limit and define the conditions that stop traffic: abnormal error rate, unresolved paid orders, settlement mismatch or repeated redirect failure. The team should know who owns each escalation before the first customer complains.

1. Rotate test secrets before production
2. Verify no sensitive data appears in logs
3. Test with firewall and WAF enabled
4. Prepare support evidence checklist
5. Define go-live, rollback and traffic-increase thresholds

Evidence to retain for the production sign-off

The following checklist turns the article into an operating document. Assign an owner, record completion and keep the result with the merchant configuration or incident. A checklist is valuable only when the team can show evidence for each item rather than assuming that someone tested it.

Review the list after any major route, wallet, domain, plugin or fee-policy change. Payment systems drift over time: certificates renew, providers change behavior, store plugins update and staff permissions change. Repeating the relevant controls is cheaper than discovering the gap through a customer complaint.

• Screenshot or export of merchant fee and payout settings.
• List of tested routes, amounts, countries and devices.
• Webhook event log showing authentication and duplicate handling.
• Order history showing exactly one fulfillment for repeated notifications.
• Live settlement transaction hash on the configured network.
• Dry-run reconciliation report for unresolved sessions.
• Named owners for checkout, support, treasury and provider escalation.

Conditions that should block launch

The following checklist turns the article into an operating document. Assign an owner, record completion and keep the result with the merchant configuration or incident. A checklist is valuable only when the team can show evidence for each item rather than assuming that someone tested it.

Review the list after any major route, wallet, domain, plugin or fee-policy change. Payment systems drift over time: certificates renew, providers change behavior, store plugins update and staff permissions change. Repeating the relevant controls is cheaper than discovering the gap through a customer complaint.

• An order can be fulfilled by opening or modifying a browser URL.
• The receiving wallet network has not been verified.
• Webhook authentication is disabled or unknown.
• Test sessions cannot be found from the merchant order number.
• A failed route shows raw credentials or stack traces.
• Duplicate events create duplicate delivery or affiliate credit.
• Support cannot distinguish payment confirmation from settlement arrival.

How a senior launch review is conducted

A senior reviewer does not ask only whether each test passed. They ask what evidence proves the result and what would happen if the same event occurred twice, late or out of order. For example, a valid paid webhook is only one test. The reviewer also sends the same event again, sends an older pending event after paid, blocks the store endpoint temporarily and confirms that reconciliation repairs the order without repeating delivery.

The reviewer checks observability as carefully as functionality. Every failed session should produce a searchable merchant-safe error and an internal diagnostic reference. Every status transition should identify its source. Every payout should show asset and network. When a launch issue occurs at 2 a.m., the team should be able to investigate from the dashboard and logs without adding debug code to production.

Performance testing should reflect the real environment. Open several sessions at once, repeat from mobile networks and verify that database locks or provider calls do not make the checkout appear frozen. Confirm that slow provider responses have timeouts and user-friendly fallbacks. A route that eventually responds after the web server has already timed out will create orphaned sessions and customer retries.

The final review includes a rollback. The merchant must know how to disable one route, pause the payment method or return to a maintenance message without deleting orders. A reversible launch is safer than a launch that requires emergency code edits. Record the configuration that passed testing so it can be restored after unrelated changes.

After sign-off, monitor the first production sessions manually. Compare each store order, platform session, provider result and settlement. Automated dashboards are important, but a small-volume launch benefits from human review because it reveals wording and support issues that automated checks cannot predict.

Additional implementation controls

Create a written production sign-off that names the exact plugin or API version, live domain, webhook URL, configured wallet, active fee mode and route list. Attach the word-count-free evidence from the tests rather than a simple “passed” statement. When the system changes later, the sign-off becomes the reference for determining whether the new problem existed at launch or was introduced by an update.

Schedule a post-launch review after the first ten real payments or seven days, whichever comes first. Compare production behavior with the test results and add any newly discovered customer pattern to the permanent regression checklist. A launch checklist should grow from verified incidents, not remain a document used only once.

Why one successful payment can hide a dangerous integration

A merchant tests a €10 payment on desktop and sees the provider success screen. The store receives the browser return and immediately marks the order completed. The team assumes launch is finished. The next day a mobile customer closes the provider page after authorization, the webhook arrives eight minutes later and the customer refreshes the return page three times. The store sends four delivery emails because fulfillment is tied to page load.

A complete test matrix would have exposed the problem. The corrected integration stores the event ID, accepts duplicate callbacks idempotently, uses the server-side paid status as the only fulfillment trigger and renders the return page as a status viewer. The customer may refresh safely, and delayed confirmation does not create duplicate delivery. The difference is not a new payment provider; it is disciplined launch testing.

Go-live decision rule

1. All normal and failure-path session tests pass without exposing sensitive errors.
2. No order can become paid from a browser-controlled request.
3. Duplicate webhooks and page refreshes cannot duplicate fulfillment.
4. At least one live payment is matched to verified settlement evidence.
5. Support can trace an order from merchant reference to platform session, provider reference and payout.
6. The first production traffic increase is limited and reversible.

A launch should be delayed when any paid order cannot be reconciled, when wallet configuration is uncertain, or when the team cannot distinguish pending from failed. These are not cosmetic defects; they directly affect money and customer trust.

Frequently asked questions

Do I really need 50 tests for a small store?

You may combine some tests, but the underlying failure cases still exist. A smaller merchant often has less support capacity, so preventing duplicate fulfillment and lost payment evidence is even more important.

Can I test everything without real money?

Most integration behavior can be tested with controlled sessions, but at least one small live payment and settlement is necessary to validate the full provider and wallet path.

What is the most important launch test?

Confirm that the order becomes paid only from verified server-side evidence and that the paid event can be received more than once without duplicate fulfillment.

How often should reconciliation run?

It should run often enough to recover delayed or missed callbacks within the customer support expectations of the business. The exact interval depends on provider timing and system load.

Should I test every payment route?

Yes. Different routes can have different minimum amounts, country availability, verification behavior and callback timing. One route’s success does not validate another.