Point-of-sale payment integration testing checks that point-of-sale (POS) software exchanges transaction data correctly with a payment terminal and the connected processor or acquiring service. It verifies that approvals, declines, cancellations, timeouts and other responses produce the right transaction state in the POS, with accurate amounts and records across the systems involved.
What point-of-sale payment integration testing covers
A POS payment may pass through the till application, a card terminal, a payment gateway or processor, and an acquiring service before an authorisation response returns. The exact components depend on the merchant's setup. Integration testing focuses on the hand-offs between those components: whether each request contains the required data, whether responses are interpreted correctly, and whether transaction state remains consistent.
Tests commonly cover supported payment methods and transaction flows, including sale, cancellation and refund where these are part of the integration. They check data such as amount, currency, merchant or transaction reference, and payment status. They also verify how the POS behaves when a response is delayed, rejected, malformed or absent.
The test boundary should be explicit. A POS-to-terminal integration test can validate communication between those components. A broader end-to-end test may follow the transaction through authorisation, clearing, settlement and reconciliation. Authorisation success alone does not prove that settlement or reconciliation has worked.
Preconditions and dependencies
Use a controlled test environment with the required terminal configuration, processor or gateway test access, and test credentials. The POS, terminal and service should use compatible configuration and transaction identifiers. If one dependency is unavailable, a simulator or service virtualisation can exercise the POS response handling, though it cannot confirm behaviour on the live external service.
Prepare repeatable test data and define expected outcomes before execution. Avoid live payment credentials and real customer card data in test runs. Keep sensitive authentication data out of logs and test evidence. Environment drift, such as different terminal settings or service versions between test and release, can make results unreliable, so record relevant configuration with the run.
Example: approved sale and uncertain response
For a test sale of £24.50, send the payment through the POS and a processor test environment. On an approved response, verify that the terminal and POS show approval, that the POS records £24.50 in the expected currency, and that the transaction reference is consistent across the available records. Check that the sale produces the expected receipt and is not recorded twice if the same response is delivered again, where the integration supports repeat delivery.
Then simulate a timeout after the request reaches the processor. The test should confirm the configured behaviour for an unknown outcome. The POS might display a pending or unresolved state and provide a safe recovery path. It should not mark the sale as approved without evidence, or create a second charge through an uncontrolled retry. Check the resulting status and references against processor test records or interface logs. A timeout does not by itself show whether the processor authorised the payment.
Verifying failures and diagnosing defects
Include declined payments, terminal cancellation, loss of connectivity, delayed responses and duplicate messages where supported by the interface. Assert both the user-visible result and the stored transaction state. For example, a decline should not create a completed sale, while a cancellation should follow the configured cancellation flow and leave an auditable outcome.
When a test fails, compare the request and response at each boundary, using masked data. Check status mapping, amount formatting, reference propagation, retry behaviour and the final POS record. A correct processor response can still expose an integration defect if the POS displays the wrong result or records a different amount. Conversely, a POS display defect may sit outside the payment service itself, so trace evidence across the full tested boundary before assigning ownership.
Frequently asked questions
Does point-of-sale payment integration testing include settlement?
It includes settlement only when the defined test boundary covers clearing and settlement services. A POS-to-terminal authorisation test does not establish that funds were settled or reconciled.
Can payment integration tests use real customer card details?
Use processor-approved test credentials and test data in a controlled environment. Real customer card details should not be introduced into test runs or retained in logs and evidence.
Do tests need physical payment terminals?
Physical terminals are needed when the test must verify device behaviour or the actual POS-to-terminal connection. A simulator can test message handling and response logic, but it cannot confirm physical-device interaction.
How should a test verify an issuer decline?
Use a documented test scenario that returns a decline from the processor test environment, then verify the POS status, transaction record and customer-facing result. Confirm that no completed sale is recorded for the declined payment.