Payment testing: a checklist with no "pay and see"

Payment is the only flow where a defect costs money directly, and the only one most teams check in a single way: pay and confirm it went through. Everything interesting happens on declines, timeouts and retries — where the user presses the button a second time.

Successful scenarios

• Payment by every connected method: card, banking app, wallet, QR, instalments — each separately, not "once by card".
• Payment with a saved card and a new one; saving the card with the user's consent and without.
• Minimum and maximum amount, an amount with cents, an amount with a discount and a promo code.
• Different currencies if the product is multi-currency: conversion, rounding, display in the receipt.
• Order status after payment, confirmation email and push, the history entry — all within the expected time.

Declines and edge cases

This is where the defects live that turn into double charges, stuck orders and disputes with users. For every payment method we run the same set: decline, cancellation, timeout, retry.

• Gateway decline: insufficient funds, blocked card, limit — the user sees a clear message and can try again.
• User cancellation on the gateway screen: the order does not hang in "pending", the user can go back and choose another method.
• Gateway timeout: what the user sees, what happens to the order, whether a duplicate is created on return to the app.
• Pressing "Pay" again: protection against a double order and a double charge.
• Network loss at the moment of payment: order status after recovery, reconciliation with gateway data.
• Payment after the stock reservation or promo code has expired: a correct decline, not a payment on old terms.
• Partial failure with several items or split payment.

Webhooks, refunds and reconciliation

• The successful-payment webhook: arrives, is processed once, redelivery does not create a second order.
• The webhook arrives before the user returns to the app, or after — both orders.
• Full and partial refund: order status, amount, timing, notification to the user.
• Refund after partial shipment or after part of a bonus was used.
• Reconciliation: amounts in the product, the gateway dashboard and accounting match for the period, including cancelled and refunded.

How to test without losing money

1. The gateway's test mode with test cards and decline scenarios — for most checks.
2. Minimal real amounts under an agreed protocol — for scenarios test mode does not reproduce: specific banks, wallets, instalments.
3. Emulating timeouts and network loss on the client side — through a proxy such as Charles or network throttling on the device.
4. Gateway and product logs for every scenario — to reconcile what the user saw with what actually happened.

Specifically for the region

In Kazakhstan, Uzbekistan, Belarus and other CIS countries payment goes through local systems — Kaspi, Click and Payme, ERIP, Elcart, m10 — each with its own test mode, its own timeouts and its own decline behaviour. The scenario set is the same, but it has to be run on each system separately and on devices with the country's SIM cards: some wallets and banking apps are available only from local numbers.