UAT and regression
UAT by region and scheme, regression and issuance verification — acceptance testing before going live.
What this layer verifies
This layer confirms whether terminals and cards that have passed certification are actually accepted in the live market, at the processor and across the debit networks. It fills the gap between the certification tools and the live market, looking at conformance to operating conditions rather than to the specification.
| What you want to confirm | Product |
|---|---|
| Running transaction UAT by region and scheme with physical cards, mainly contact | B2 EMV test card sets |
| Transaction UAT for contactless and dual interface, and acceptance checks with real wallets | Touchless Dual Interface Collection |
| Checking US Common Debit AID selection and routing as one chain, from the terminal through to the receipt | USA Debit Test Card Set |
| Checking 8-digit BIN support across the payment application, the host, routing and the BIN database | 8-Digit BIN Test Card Set |
| Transaction UAT for special cases such as EBT | UAT EBT Card |
| Running transaction coverage and regression automatically | PaytestLab/PaytestHub/PaytestRobot |
Where working with physical test cards tends to go wrong
Even once the cards arrive, a transaction will not complete unless the following are in place. We confirm these before ordering and before use.
| Item | Detail |
|---|---|
| Host support for the test BIN | A card may read at the terminal and still fail online authorisation if the processor has not registered the test BIN. Interac BINs, 8-digit BINs, Mastercard BIN 2, US Common Debit, DCC foreign BINs and Fleet BINs need particular attention |
| Test CA public key | If the scheme's test CA public key is not loaded in the terminal, transactions fail in SDA, DDA and CDA. Check the CA Public Key Index, how keys are loaded, key expiry, and separation from production keys |
| Blocking of the offline PIN | Repeating an incorrect offline PIN decrements the PIN try counter and can block the card permanently. We recommend recording the correct PIN, the number of attempts and whether the card can be reused in a card register |
| Card expiry | Public information mixes long-dated cards with outdated entries. We obtain a per-card expiry list at the time of shipment |
Relationship to certification
Passing a test with a test card is not the same as passing scheme or acquirer certification. The cards in this layer are useful for clearing obstacles before moving to formal certification, but they are not certification tools. If the results are to be used for formal certification, confirm which of the payment scheme, acquirer, processor, gateway, certification laboratory or terminal vendor needs to approve them.
Issuer side and terminal side
Cards described the same way serve different purposes. Cards for verifying terminal configuration (ICC Merchant Test Cards) and cards for transaction UAT, from B2, are different things. Because of that distinction, the two vendors' products never end up on the same shelf.
Automation divides into three layers
Automation of transaction testing has three layers: Authoring, management and execution (PaytestHub); EMV Level 3 execution (PaytestPlayer); physical operation of the terminal (PaytestRobot). Each can be used on its own or introduced in stages. Long regression runs proceed without anyone present, and the variation in how a person operates the terminal no longer affects reproducibility.