28 Oct 2026 Payment testing for webshops: what to check before checkout fails

In short: Payment testing checks that every way a customer can pay works from start to finish. That means the payment itself, but also declines, card checks, late messages from your provider, refunds and the order status in your other systems. Most payment problems sit in those edges. Automate the stable flows against your provider’s test environment and run them in every regression.

Checkout is the one page where a bug costs you money straight away. Yet in many webshops the payment link is tested once, at launch, and then left alone. Then the provider changes something, a new payment method goes live or the order system gets an update. Nobody notices until customers start calling. Good payment testing makes sure you hear it first.

What is payment testing, and why does it break after launch?

Payment testing checks the whole chain from the “pay” button to a finished order in your systems. That chain has more links than most people think. There’s your shop, and there’s the payment service provider, the company that handles the payment between your shop and the banks. Then come the customer’s bank or app, the status message back to your shop, and your order, stock and email systems. Each of these parts changes on its own schedule. Your provider updates its platform. A bank changes its app. Your team adds a payment method or a discount rule. Any of these can break the chain without a single line of your own checkout code changing. At e-commerce clients we often see the same thing. A new integration gets checked once, and then it never makes it into the regression or sanity tests. Payment is the clearest example of that.

The result is a quiet kind of failure. The payment works, but the order stays on “pending”. Or the customer pays twice, or a refund never reaches the bank.

What should you test in a payment flow?

Test the edges, not only the happy path where everything goes right. A successful card payment on a desktop is the case everyone checks. The incidents come from what happens around it. Use this list as a starting point and match it to the payment methods you offer.

• Every method on every device. Cards, wallets and local methods, on desktop and on mobile.
• Declines and cancels. A refused card, a customer who stops at the bank, a session that times out. The order should stay unpaid, the stock should return and the customer should see a clear message.
• Strong customer authentication. In the EU, most online card payments need an extra check, such as a code in the bank app. The EU rules on strong customer authentication set this out. For cards it runs through 3-D Secure. Test the extra check, the flow without it and a failed check.
• Status messages. Your provider sends your shop a message when a payment succeeds or fails. Test what happens when it arrives late, twice or not at all. A double message must not create a double order.
• Refunds. Full and partial refunds, started from your shop and from the provider’s dashboard.
• Amounts. Discounts, shipping, VAT, currency and rounding. The amount charged must match the order total.
• The chain behind the shop. Order status, stock, invoice and confirmation email after each outcome.

How do you automate payment tests?

You automate payment tests against your provider’s sandbox, a test environment that behaves like the real thing without moving real money. Providers offer test card numbers that trigger set outcomes, such as a success, a decline or an extra security check. Stripe and Adyen both document theirs. That makes every case on the list above repeatable. Keep your own test data under control too. At e-commerce clients, automated tests often fail because test data isn’t managed or keeps changing in shared environments. The fix is a fixed, reproducible set of test customers, products and discount codes.

Not every check needs a browser. You can test status messages faster on the API level, by sending the shop a fake message twice or late. Keep one full UI journey per main payment method on top, as part of your end-to-end testing of the whole webshop chain. Then run the whole set in every regression run, so a change anywhere in the chain shows up the next morning.

Two trade-offs to name. A sandbox is not production: some methods behave a little differently, and a real bank app approval is hard to automate. So many teams also do a small real payment after a big release. And automation doesn’t replace people. When you add a new payment method, a tester should try it on a real phone, the way a customer would.

What this means for your team

Payment tests only protect you while they keep running. Providers change their test environments, test cards get replaced and new methods arrive. Every change in your shop can also mean a test needs updating. In many webshop teams that upkeep lands on whoever built the tests, and slips when that person is busy or leaves. That’s how payment ends up tested once and then forgotten.

With Test Automation as a Service, we build those payment tests together with your team. They run every night with the rest of your regression suite, next to the checks on stock, ERP and delivery that our e-commerce testing covers. When your provider or your shop changes, we keep the tests reliable. You get a stable test suite your team can trust, one that doesn’t depend on a single person.

A first step you can take today: list every payment method you offer. Then check which of the cases above your current tests really cover.

Frequently asked questions

What is a payment sandbox?

A sandbox is a test environment from your payment provider. It works like the real platform, but no real money moves. Test card numbers let you trigger outcomes such as a decline.

Can you test payments in production?

Only in a small, controlled way, such as one real payment after a big release, followed by a refund. Do all other testing in the sandbox, so customers and your books stay unaffected.

How do you test 3D Secure?

Use your provider’s test cards that trigger the extra check. Then test three outcomes: the customer passes the check, fails it, or isn’t asked at all.

How often should you run payment tests?

Run them automatically in every regression run, at least every night. Also run them after any change to your checkout, your provider settings or your order system.