How to test an e-commerce payment gateway: 3D Secure, webhooks and refunds
A payment integration is not complete merely because one test payment ended with confirmation. Delays, retries and outages can occur between the customer’s click, the bank’s response, the return to the shop and the gateway’s server notification. This checklist helps product, engineering and QA teams verify the integration before deployment; live monitoring remains a separate task.
Why a payment is a series of states, not one redirect
The customer’s browser and the shop’s server receive the result through different routes. The customer may return to a thank-you page, close the tab or lose their connection. Independently, the gateway may send a webhook: a server notification that a payment state has changed. The order needs clear rules defining which verified state is authoritative and which events may reserve stock, issue an invoice or send an email.
Map the supported payment states and their transitions first. Names differ between providers, but you usually need to distinguish pending, successful, declined, cancelled and refunded payments. For the complete shopping journey, see the broader guide to automated e-commerce testing. Here, the focus is the integration interface and order state.
Pre-production checklist
1. Successful and declined payments. Verify the amount, currency, order identifier and final state in both the shop and gateway dashboard. The order, confirmation and accounting records should be created exactly once. After a decline or technical error, the customer should have a clear way to try again, but the order must not appear paid. Use only test data recommended by your provider; for example, Stripe documents separate test scenarios for success, declines and authentication. This illustrates one supplier’s facilities, not a universal list.
2. The complete 3D Secure flow. 3D Secure is an additional cardholder verification step that may take the customer to a challenge from their bank. Test successful verification, cancellation by the customer, failure, an error and a timeout. Also try the back button, a page refresh and resuming after interruption. Every branch should end in a predictable state and must not create a second payment or order.
3. The customer’s return is not the only source of truth. Close the tab before returning to the shop and deliver the webhook later. Then perform the opposite test: the customer returns while the webhook is delayed. The interface may temporarily show “verifying payment”, but it should not infer success from the return-page URL alone. Verify that the later server-side state safely completes the order and that the customer can learn the result without paying again.
4. Double-clicks, repeated attempts and idempotency. Slow the network, press the button twice and repeat a request after an apparent timeout. Idempotency means that repeating the same operation does not produce a second business outcome. If the gateway supports an idempotency key, use it according to its documentation, while also protecting order creation with a unique business identifier in your own system. Test concurrent requests as well as consecutive retries.
5. Webhooks in an inconvenient order. Verify the signature on the original request body as specified by the supplier. Reject invalid signatures; safely ignore or log valid event types you do not process and acknowledge them as required by the gateway contract. For Stripe, this usually means returning a prompt 2xx response. Deliver the same event twice, send a newer state before an older one, and retry after an endpoint error or timeout. Processing must tolerate duplicates and must not assume unguaranteed ordering. Stripe documents retries, duplicates and non-guaranteed ordering; check another gateway’s own contract and documentation.
6. Order state and side effects. For every scenario, inspect the database, stock, email, billing and customer account. An event received twice must not deduct stock twice or send two invoices. A declined or incomplete payment should not activate a paid service. Also agree whether an unpaid order is created at all and how long its reservation lasts; the test should verify your rule, not invent it.
7. Full and partial refunds. Test the full amount, a partial amount and, where supported, multiple partial refunds within the permitted total. Check the order transition, its presentation in the customer account, the credit note and the information available to support. A refund can have an intermediate or failed state of its own, so checking the response to the first API request is not enough; the team needs to reconcile the final result with the gateway event.
What a sandbox cannot confirm
A sandbox or test mode simulates selected outcomes without moving real money. It may not reproduce bank rules, fraud controls, timing, payment-method availability or the live account configuration. Before deployment, therefore, compare test and live keys, enabled currencies and methods, return addresses, the webhook endpoint, signing secret and API version. Agree the scope of any safe live check with operations and the provider in advance; not every integration needs the same form of check.
After deployment, monitor the ratio of initiated, successful and declined payments, delayed or failed webhooks, mismatched order states and completion time. This observation complements the release checklist but does not replace it. A separate guide explains how to design safe ongoing payment-gateway monitoring.
What you gain
Tests designed this way expose defects in state transitions, not only on the final screen. Before release, the team can demonstrate that duplicates, delays, and interruptions do not create an unexpected business outcome within the verified scope. The same expectations then help support and operations diagnose a real incident.
Next step: close the checklist
For each scenario, record the expected payment state, order state, permitted side effects and evidence in the log. Then name the owner who can assess a failure before release. The result is not just one successful test payment, but repeatable evidence that the integration handles interruption, duplication and delay without losing or duplicating an order.