12 Tests Every Payment Integration Must Pass

Payment issues are often rare but have a significant impact. A customer might pay twice, an order might remain open by mistake, or a refund might only be visible in one system. With a fixed test set, you can make these exceptions predictable.

Transaction Statuses

  • Payment processed successfully with the correct amount and reference
  • Refusal to pay, with the sale remaining open
  • Customer cancels without an incorrect payment status
  • Timeout, after which the final status is retrieved

A reliable flow starts with a Secure connection between your point-of-sale system and payment terminal or payment API.

Duplicate and Delayed Messages

  • Double-click or repeated request without a duplicate transaction
  • The webhook is triggered twice without causing a duplicate effect
  • Webhook arrives late or in a different order
  • The return page is accessed without a confirmed provider status

Do you want to understand first? How a POS integration works? Be sure to check out the technical explanation as well.

Refund and Correction

  • Full refund with updated checkout or order status
  • Partial refund where supported and the correct amount is shown
  • Refund Denied or Paused with Clear Follow-Up

Refunds and adjustments are also important when selling online; be sure to check out our information on e-commerce payments.

Recovery and Security

  1. Restart the POS system, terminal, router, or integration service during a transaction and verify that it recovers. Also, test for expired credentials, insufficient permissions, and sandbox-production separation.

Logs should provide sufficient context without containing map data or secrets.

Test with unique references

Use unique identifiers for each order and payment attempt. Specify which status takes precedence and how an operator should retrieve a transaction. This prevents a test from being evaluated based solely on screen shots.

Keep a record of the scenario, expected outcome, actual outcome, software version, and date.

Retest after updates

Repeat the critical scenarios after major POS releases, plugin updates, terminal firmware updates, or API changes. Automate wherever possible, but maintain an end-to-end test using actual test hardware and the provider’s environment.

Assign an owner to be responsible for releasing the new version.

Making the right choice starts with how you operate

A payment integration is ready for production when the team knows what happens in both successful and uncertain scenarios. A fixed regression test protects you from problems that may resurface after updates.

Test Before Your Customers Do

OmEs pay works with your POS or software vendor to verify terminal and provider behavior and documents the practical troubleshooting procedure.