Payment Integration Testing: Five Checks Before Going Live

Before going live with online payments, test five things in your provider's test environment: a full successful payment, declined and failed payments, full and partial refunds, webhooks that are verified and safe to receive twice, and monitoring after launch. This payment integration testing checklist helps you find problems before real customers do.

In short:

• Check 1: a successful payment, followed all the way through your own system.
• Check 2: declined and failed payments, with clear messages for the customer.
• Check 3: full and partial refunds, and how your records update.
• Check 4: webhooks that arrive, are verified and are safe to receive twice.
• Check 5: monitoring after launch, with a named owner.

A payment integration that works once on your laptop is not the same as one that is ready for customers. The cases that cause trouble later are the ones you did not try: a declined card, a refund for half an order, a notification that arrives twice.

A test environment is a copy of your provider's system where no real money moves. Work through each check there, and write down the result.

Check 1: Test a successful payment end to end

Payment integration testing begins with one normal order, followed all the way through, not only to the "thank you" page.

• Place an order as a customer would, from product page to payment to confirmation.
• Confirm that your own system records the order as paid, once, with the right amount and currency.
• Check what the customer receives: the confirmation and receipt.
• Check what your team sees: the order in your back office, the payment in your provider's dashboard, and whether the two match.

If your checkout is embedded on your own domain, confirm it loads only where you expect; see how to whitelist a website. For what happens after the customer pays, see how a card payment moves.

Check 2: Test declined and failed payments before going live

A decline is when the customer's bank or the provider refuses a payment. Real customers will see them, so simulate them using the methods your provider documents, never real card details.

Test several kinds of failure, because they look different to the customer:

• A decline by the card's bank. The customer should see a clear, calm message and a way to try again or use another payment method.
• A technical failure, such as the request timing out or the page being closed halfway. Your system should not mark the order as paid, and the customer should not be left wondering whether they were charged.
• A customer who abandons the payment or stops at an identity step. The order should stay unpaid, and any stock you reserved should be released according to your own rules.

For each case, read the message the customer actually sees. A good one says what happened, what to do next and how to reach you, without internal details or blame. If your checkout adds an identity step, see what 3-D Secure is and why it matters.

Check 3: Test full and partial refunds

A refund returns money to the customer after a sale. It touches more parts of your business than a sale does, so test it before you need it.

• Issue a full refund on a test payment and see how it appears in your provider's dashboard and in your own system.
• Issue a partial refund, for example for one item in an order, then confirm the remaining amount is still correct.
• Try to refund more than was paid, or refund the same payment twice. Your setup should refuse or flag it clearly.
• Check the customer message, the order status, and your own books: stock, discount codes, invoices or credit notes.

Decide who can issue refunds and how customers are told. For the mechanics, see how to refund a transaction and how card refunds work.

Check 4: Test webhooks before going live, including duplicates

A webhook is a message your provider sends to a web address you control, telling you that something happened. It is often the most reliable way to learn that a payment succeeded, failed or was refunded, because the customer's browser may close before it returns to your site.

Test these points:

• Delivery. Does the notification reach your endpoint for each event type you rely on: success, failure, refund and anything else you handle?
• Verification. Your endpoint should check that a message really comes from your provider, using the signature method in their documentation, and reject anything that does not pass. Our guide on how to set up webhooks explains the setup.
• Handling the same event twice. Providers retry when they do not get a successful reply, so the same event can arrive more than once, and sometimes out of order. Your handler should be idempotent, which means processing a duplicate changes nothing the second time. It must not create a second order, a second email or a second refund. Storing an event identifier and ignoring repeats is a common approach.
• Secrets. Check that your keys and signing secrets are stored safely, are not in your code repository or browser code, and can be rotated. See our guide on how to manage API keys.

Check 5: Monitor payments after launch

Testing does not end at launch. This check is owned by your own team, not only by your provider.

• Decide what you will watch. At minimum: the share of payment attempts that succeed, the number and reasons for declines, refunds, and disputes raised by customers through their banks. A dispute is also called a chargeback; see what a chargeback is and how it works.
• Choose a baseline and review rhythm. Note what normal looks like after your first real payments, then review on a regular schedule.
• Set alerts for the unexpected, such as a sudden change in success rate, failed webhooks or a spike in disputes.
• Name an owner. One person, or one role, should be responsible for reading these numbers and for knowing who to contact at your provider.

Before you switch to real payments

Re-run Check 1 with the real configuration, and make sure test and real keys are not mixed up. Confirm your webhook address and signing secret are set for the real environment too. Finally, make sure your account verification with your provider is complete; our guide on how to complete KYB verification explains what is usually asked.

Key takeaways

• Test the whole journey, not just the first successful payment.
• Declines and failures are normal; make sure the customer sees clear messages and you never end up with duplicate or wrongly paid orders.
• Test full and partial refunds, and check that your own records update.
• Verify webhooks and make your handler safe to receive the same event twice.
• Monitor success, declines and disputes after launch, with a named owner on your team.

Frequently asked questions

What should I test before going live with online payments?

Test five things in a test environment: a full successful payment, declined and failed payments, full and partial refunds, webhooks including duplicates, and a monitoring plan for after launch. Write down the result of each, and repeat the successful payment with real settings before switching over.

What is a test environment in payment integration testing?

A test environment is a separate copy of your provider's system where payments are simulated and no real money moves. You use it to try successful payments, declines, refunds and webhooks safely, with test keys that are kept apart from your real keys.

Why can the same webhook arrive more than once?

Providers resend a webhook when they do not receive a successful reply from your server, for example after a timeout. That means duplicates, and sometimes out-of-order messages, are normal. Your handler should recognise an event it has already processed and do nothing the second time.

How do I test a declined payment without using real card details?

Use the methods your provider documents for simulating a decline inside the test environment. Never use or look up real card details for this. Then read the message your customer would see and confirm the order stays unpaid.

Does payment testing end when I go live?

No. After launch, keep watching how many payment attempts succeed, why payments are declined, and how many refunds and disputes arrive. Agree what normal looks like, review it on a regular schedule, and give one person ownership of the numbers.

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.