Checkout is the one flow where a bug is never just embarrassing; it costs money and trust immediately, and sometimes it costs them twice. Testing payment flows used to stress me more than anything else on the release checklist, until I stopped treating checkout as one big scary scenario and started breaking it into small, boring, repeatable checks.
Stay in the sandbox
Every serious payment gateway ships a sandbox environment with test card numbers that trigger specific outcomes: success, insufficient funds, expired card, a 3-D Secure challenge, a network failure. I keep those numbers in a shared document, each one mapped to the scenario it triggers, so anyone on the team can reproduce a declined payment on demand. The rule is absolute: no real card ever touches a test, not even yours, not even "just once to check."
Idempotency, or the double-tap test
My favorite payment bug hunt takes five seconds: tap the pay button twice, fast. Then the longer versions: kill the app right after the request is sent, and retry after a timeout. In every case, exactly one charge should exist. The backend defense is an idempotency key, a unique value per payment attempt that the gateway uses to deduplicate retries; if your backend is not sending one, that is a finding on its own. And I never trust the confirmation screen to tell me how many charges happened. The database knows; the UI guesses.
Currency and rounding will bite you
I test from Jordan, where the dinar has three decimal places, which has broken more than one integration that assumed every currency has two. Check how amounts are stored (minor units or decimals), how discounts and taxes round, and whether the total shown in the cart, the amount sent to the gateway, the confirmation screen, and the receipt all agree to the last digit. A one-fils mismatch is still a mismatch, and the finance team will find it even if users never do.
Testing payment flows for failure and recovery
A declined card is a normal event, not an edge case, so the recovery experience deserves as much testing as the success path. After a decline: does the user see a reason they can act on, is the cart still intact, can they retry with another card without re-entering everything, and did the failed attempt avoid creating a ghost order stuck in a pending state? Then refunds: full, partial, a second partial after the first, and whether the gateway's webhook actually updates the order status when the refund settles.
Reconcile with SQL before you sign off
After a test run, I query the database to prove that orders and captured charges agree:
SELECT o.id, o.total, SUM(t.amount) AS captured
FROM orders o
JOIN transactions t ON t.order_id = o.id
WHERE t.status = 'captured'
GROUP BY o.id, o.total
HAVING o.total <> SUM(t.amount);Every row this returns is a bug: an overcharge, an undercharge, or a duplicate. Five minutes of SQL here regularly catches what hours of UI testing cannot.
What never to do in production
No test cards against production. No "small real charge just to verify," because now you are testing the refund flow involuntarily. No hand-editing payment rows in the production database, and no replaying gateway webhooks at production endpoints to see what happens. If a production verification is genuinely needed, it gets planned with the team, with the refund path agreed on before anyone is charged.