Three Payment Failures to Test Before You Launch

Before you take real payments, test three failures in your provider's test environment: a declined card, a slow response, and the same notification arriving twice. A successful payment proves your happy path works. These three tests show what customers and your own systems will see when something goes wrong.

• Declined card: check what the customer sees and what your system records.
• Slow response: check that your page waits sensibly and does not charge or ship twice.
• Repeated notification: check that receiving the same message twice does not repeat the work.

This guide is the written companion to our short video on the same topic.

Why is a successful test payment not enough?

A successful payment only proves the path where everything goes right. Real customers meet declines, slow networks and repeated messages, and those are the moments that create support tickets and lost orders. Testing them in a test environment costs nothing, while discovering them with real customers does.

If you want the wider checklist, read five checks before taking real payments. This article goes deeper on three of the failure cases.

How do you test a declined card?

Use a test card or test setting from your provider that produces a decline. Providers publish their own test cards and scenarios, so check their documentation, because the details differ.

Then check three things. What message does the customer see? Does your system record the decline code for your own use? Does the order stay unpaid instead of being marked as paid? Our guides on why a card payment gets declined and what to tell a customer after a card decline explain what the message should say.

How do you test a slow response?

A payment request can take longer than expected, or the answer can fail to arrive at all. If your provider's test environment lets you simulate a delay, use it. If it does not, you can add a delay on your own side to see how your page behaves.

Check what the customer sees while waiting, whether a second click on the pay button can start a second payment, and what your system does if no answer ever comes. The safe goal is simple: the customer is never charged twice because they waited and clicked again.

How do you test the same notification arriving twice?

Your provider tells your system about payment results with notifications, often called webhooks. A notification can be sent more than once, for example when your server was slow to answer the first time. Our article on payment webhooks explained covers what they are.

Send the same test notification twice. Check that your system marks the order as paid once, sends one confirmation, and does not ship or credit anything a second time. Handling a repeat safely is part of a reliable integration.

What should you write down?

For each test, write down what you did, what the customer saw, and what your system recorded. Fix anything surprising, then run the test again. Keep the notes with your go-live checklist so the next person can repeat the tests after a change.

Frequently asked questions

Why test failures before launch?

Because customers will meet them. A decline, a slow answer or a repeated message is normal in card payments, and testing them in a test environment lets you fix problems before they cost you orders or create double actions.

How do I make a test payment decline?

Your provider may publish test cards or settings that produce a decline in their test environment. The details differ between providers, so check your provider's documentation for the scenarios they support.

What should happen if the payment response is slow?

The customer should see a clear waiting state, and a second click should not start a second payment. If no answer arrives, your system should check the payment's status instead of assuming it failed or succeeded.

Why might I get the same notification twice?

A provider may resend a notification if your system did not answer in time or answered with an error. Your system should treat a repeated notification as already handled and avoid repeating the work.

How often should I repeat these tests?

Repeat them after any change to your checkout or payment code, and before launch. Keep your notes so the same tests are easy to run again.

Where to go next

EPaySe is a payment gateway in development for high-risk and regulated businesses, reviewed and approved case by case. If you have questions about your own setup, contact the EPaySe team.

This article is general information, not legal, tax or financial advice. Check with your own advisor before making decisions about your business.