Test Cases for Payment Gateway: Complete QA Checklist

A customer who sees an error may still have been charged. That ambiguous state is the defining payment risk: the browser, merchant server, gateway, acquirer, and webhook processor can each know something different at the same moment. Retrying without reconciliation can turn one purchase into two charges.

Payment tests must assert financial state across systems, not only the checkout message. Use the gateway's sandbox and approved test instruments, keep real card data out of test environments, and give every attempt a traceable merchant reference.

Draw the Payment State Machine

List the states supported by the product, such as created, requires action, authorized, captured, failed, cancelled, partially refunded, refunded, disputed, and expired. Record the allowed transitions and which actor can cause each one. A payment cannot be tested reliably if “success” could mean authorization, capture, or settlement depending on the screen.

Define the source of truth for an order when the synchronous API result and later webhook disagree. Usually the merchant backend reconciles gateway state rather than trusting a client redirect.

Prepare Safe, Deterministic Test Data

Use documented sandbox cards, wallets, bank methods, and gateway scenarios for approvals, declines, challenges, timeouts, and delayed settlement. Include supported currencies, zero-decimal currencies where relevant, minimum and maximum amounts, taxes, discounts, shipping, and rounding boundaries.

Create unique orders and idempotency keys for each case. Record merchant order ID, gateway payment ID, attempt ID, webhook event IDs, amount in minor units, currency, and test customer. Do not reuse an order unless the case explicitly tests retries or multiple attempts.

Keep secrets in managed environment configuration and redact card numbers, client secrets, signatures, and personal data from reports. A sandbox is still a shared security boundary, not a reason to copy credentials into fixtures.

Cover Methods, Amounts, and Authentication

Complete the primary flow for every enabled method: card, wallet, bank transfer, local method, or saved instrument. Verify method availability follows currency, country, device, and merchant configuration. Unsupported combinations should be unavailable before the customer invests in the flow.

For cards, cover valid entry, invalid number, expired date, invalid security code, unsupported brand, and billing-address rules. Use only gateway-provided test values. Test a challenge that succeeds, fails, is cancelled, times out, and returns through browser back or a different tab.

Assert the exact authorized and captured amounts in minor units. Include percentage and fixed discounts, tax rounding, shipping changes, currency conversion display if offered, and a cart whose total changes after the payment session was created. The server should calculate or verify the charge, never accept a client-modified amount.

Exercise Declines, Cancellation, and Unknown Outcomes

Distinguish hard declines, soft declines, validation errors, risk blocks, insufficient funds, gateway unavailability, and customer cancellation. Show useful recovery without exposing issuer or fraud details that should remain private. A retry should create a new attempt under the same order while preserving the history of the failed one.

Include payments placed into manual risk review. The order must remain in a non-fulfillable state until approval, while rejection releases inventory or authorization according to policy. Repeated review callbacks and an operator changing the decision concurrently should produce one auditable final outcome.

Close the browser before redirect, during a challenge, after gateway approval, and before the merchant success page loads. Drop the network before sending, after sending, and while receiving the response. Refresh and double-click the payment action under latency.

For every unknown outcome, query or reconcile by stable payment reference before offering another charge. The customer may see “We are confirming your payment” instead of a false failure. The order should not ship until the chosen authoritative state confirms payment.

Prove Idempotency and Concurrency Safety

Send the same create or capture request twice with one idempotency key. The gateway and merchant service should return the original result and create one financial operation. Reuse the key with different amount or order data and expect a conflict rather than silently applying one payload.

Race two browser tabs, two mobile devices, and an API retry against the same order. Exactly one successful payment should satisfy it. If multiple attempts are allowed, later approvals need an automatic void or a controlled exception path so the customer is not left with duplicate captures.

Retry after a timeout where the gateway completed the request but the merchant lost the response. Restart the merchant worker between attempts. Idempotency must be durable, not an in-memory lock that disappears during the failure it is meant to handle.

Verify Webhooks as Untrusted, Repeated Events

Process a valid signed event, an invalid signature, missing signature, old timestamp, unknown event type, duplicate event ID, delayed event, and events delivered out of order. Acknowledge according to gateway guidance while making business processing idempotent.

An event should be matched to a known payment and merchant account. Do not trust an amount, currency, or metadata field without comparing it to the order. If capture arrives before the merchant recorded authorization due to ordering, the processor should reconcile rather than discard the final truth.

Force the webhook handler to fail before and after committing state. On redelivery, it must complete missing work once without duplicating email, inventory release, loyalty points, or accounting entries. Keep a searchable event record with sanitized payload metadata and processing outcome.

Test Capture, Void, Refund, and Dispute Paths

For separate authorization and capture, capture the full amount, a supported partial amount, the remaining amount, more than authorized, and after authorization expiry. Void before capture and repeat the void. Confirm order, gateway, and customer-facing status use precise terms.

Refund a full capture, one partial amount, several partial amounts up to the total, and one amount beyond the refundable balance. Submit duplicate refund requests and simulate a timeout. Refund acceptance may be asynchronous, so distinguish requested, succeeded, and failed rather than marking money returned too early.

Verify fees, tax adjustments, inventory policy, invoice or credit note, notifications, and ledger entries. For disputes or chargebacks supported in the sandbox, test the order state and operational alert without automatically treating every dispute as a refund.

Reconcile Orders, Gateway Records, and Ledgers

Build queries or reports that find paid orders without captures, captures without paid orders, amount or currency mismatches, duplicate successful attempts, and refunds not reflected in the merchant ledger. Run reconciliation after delayed and out-of-order webhook cases.

Totals should reconcile at transaction level before aggregate reports are trusted. Compare gross amount, refund amount, fees where available, and net amount using the same precision rules as finance. Preserve immutable references between order, payment, capture, refund, and webhook records.

Include settlement delays, currency conversion, and payout cutoffs when the integration exposes them. An authorization in one currency, capture in another, or refund after an exchange-rate change needs a documented merchant and customer amount. Reports should distinguish processor time, merchant business date, and customer-local display date. Cross a day, month, and financial-period boundary with a delayed webhook to verify revenue is not counted twice or assigned solely by event arrival time.

Test manual operational recovery with least-privilege roles. A support agent may inspect state without seeing protected instrument data, while a refund action may require stronger permission and an audit reason.

Protect the Checkout and Its Evidence

Confirm hosted fields or redirects keep sensitive card data away from merchant servers where designed. Inspect logs, analytics, crash reports, URLs, browser storage, and support views for leakage. Use HTTPS, secure cookies, content-security controls, and safe return URLs.

Manipulate order IDs, customer IDs, amounts, currencies, saved-method references, and return URLs. The backend must bind payment creation to the authenticated customer and server-side order. Test CSRF protection for browser actions and authorization for payment and refund APIs.

Exercise gateway maintenance mode and merchant configuration changes during checkout. A disabled method should stop new attempts without corrupting payments already authorized or awaiting final confirmation.

Close with a financial-story scenario that crosses every ownership boundary: complete each payment method's success route, exercise one challenge and representative declines, lose a response, race submissions, reorder webhooks, issue a partial refund, and reconcile. The scenario passes only when gateway state, merchant order, ledger, inventory policy, and customer message agree on the money.