Money movement and financial logic
POS and payment device testing
POS and payment device testing verifies card terminals, SoftPOS apps, and POS software across EMV contact and contactless flows, offline store-and-forward, firmware versions, and end-of-day batch close. FintechAssuranceLabs delivers an EMV and contactless transaction test suite, offline scenarios, a device and firmware compatibility matrix, and batch reconciliation checks for Level 3 submissions and releases.
What POS and payment device testing covers
We test the path from card to terminal to acquirer host: chip and contactless decisions, sales stored offline, firmware per device model, and the day's batch close. The failure patterns and the money they cost a POS provider are on the POS and merchant services page. Sources in this section were checked on 2026-09-16.
EMV contact and contactless transactions
- Contact flow per AID. Test cases follow EMV Book 3 section 10: offline data authentication, cardholder verification, terminal risk management, terminal action analysis, and online processing. The EMV testing requirements page maps each case to its clause and evidence.
- Contactless limits per kernel. Each amount is tested one minor unit below, at, and one minor unit above the Reader Contactless Transaction Limit, the Reader Contactless Floor Limit, and the Reader CVM Required Limit configured for that AID and kernel.
- Sale variants. Refund, void, reversal after a host timeout, and partial approval each run on contact and contactless test cards. Online sandbox tests use numbers from the test card numbers guide.
- Level 3 preparation. EMVCo states that "EMV L3 testing is defined by each payment system's policies" and that the test cases come from Participant Systems, the payment systems and other entities that use the framework (EMV Level 3 Testing). The EMV L3 Testing Framework defines test card image pseudo-functions (version 1.6, published 28 March 2023) and a common syntax for online message responses (version 1.0, published 4 August 2023). We run each payment system's test plan against the acquirer host integration before the formal submission.
Offline mode and store-and-forward
- Connection cut points. The host connection drops before the authorisation request, after the request and before the response, and after approval and before the second GENERATE AC.
- Offline decision. Under EMV Book 4 section 12.2.1, a terminal that is unable to process the transaction online shall compare the TVR with the Default values of the Terminal Action Code and the Issuer Action Code and shall set the Authorisation Response Code to "Unable to go online, offline accepted" (Y3) or "Unable to go online, offline declined" (Z3), per Book 4 Annex A6, Table 35. Each test records the code and the cryptogram type the card returned.
- Stored queue. A queued sale holds account data. PCI DSS v4.0.1 requirement 3.3.2 requires sensitive authentication data stored electronically before authorisation completes to be encrypted with strong cryptography, and its applicability notes leave the decision to permit such storage to payment brands and acquirers (PCI SSC document library). Requirement 3.3.1 requires that sensitive authentication data is not stored after authorisation, even if encrypted. Tests read the queue on the device, confirm encryption, and confirm deletion after upload.
- Upload. Visa Core Rules section 5.7.3.3 (edition of 18 April 2026) requires a deferred authorisation indicator and an authorisation request within 24 hours of the transaction date for all merchant category codes other than three transit codes (4 days) and two codes in Denmark (7 days after a temporary connectivity or system issue outside the merchant's control). Tests replay queues after a reboot, after a power loss, and with an injected clock at 23 and 25 hours after the sale, and check that a retried upload creates no duplicate sale.
Devices, firmware, and SoftPOS
- Device list. PCI DSS requirement 9.5.1.1 requires an up-to-date list of POI devices with make and model, location, and serial number or other unique identification. The applicability notes of requirement 9.5.1 exclude components used only for manual PAN key entry and commercial off-the-shelf phones and tablets. The matrix lists POI devices and SoftPOS phones in the same row format.
- Approval dates. The PCI SSC device listing states that POI v6 or higher firmware expires three years from the date of approval but not past the device approval expiration. EMVCo grants a 4-year Letter of Approval for a contact kernel and a 3-year Letter of Approval for a contactless product. Each matrix row carries these dates next to its test result.
- Updates. Tests cover an over-the-air update interrupted mid-install, a rollback to the earlier firmware, and the transaction sequence counter value after each update.
End-of-day batch close
- Capture records. EMV Book 4 section 12.1.5 states that batch data capture should convey the data elements in Tables 17 and 18, with Message Type distinguishing an offline advice from a financial record. Tests check that each offline approval reaches the batch with its application cryptogram.
- Totals. Book 4 section 12.1.6 states that a reconciliation should convey the data elements for ICC transactions, including Amount, Net Reconciliation and the number and amount of transactions per transaction type. Checks compare those totals with host capture records and the settlement file, including a close with one device offline, a resent batch, voids, refunds, and tip adjustments.
Related
Standards
Deliverables
EMV and contactless transaction test suite
Test cases per AID and kernel for contact and contactless sales, refunds, reversals, and cardholder verification limits, with APDU and host message traces, for the engineering lead and the Level 3 submission.
Offline mode and store-and-forward scenarios
Scenarios that cut the host connection before, during, and after authorisation and check the offline decision, the stored queue, and the deferred authorisation upload, for the engineering lead and the acquirer.
Device and firmware compatibility matrix
A table of terminal models, firmware versions, kernel versions, and SoftPOS operating system versions with approval expiry dates and test results, for the release manager and the acquirer's device review.
End-of-day batch reconciliation checks
Automated checks that compare terminal batch totals per transaction type with host capture records and the settlement file, and list each unmatched sale for the operations lead.
How device testing fits your release process
On every commit. POS software and the terminal payment app run against a host simulator in CI. A subset of the EMV suite runs with card simulators and test card images, so no real cardholder data enters the pipeline. A changed TVR bit, a missing capture element, or a wrong response code fails the build.
Before a firmware, kernel, or configuration release. The full EMV suite and the offline scenarios run on each device model in the compatibility matrix, on a device rack in the test environment. A programmable network switch cuts the connection at each cut point. Results go into the matrix row for that firmware version, next to its approval expiry dates.
Before a Level 3 submission. We run each payment system's test plan against the acquirer host test environment and package the APDU traces, host message traces, and receipts. Acquirer host behaviour after the terminal decision, such as capture, refund, and settlement files, is covered by payment flow testing for payment acquiring platforms.
At rollout. Firmware goes first to pilot devices. The batch reconciliation checks run on the pilot's first batch close and compare its totals with the settlement file. Merchant payouts built from those settlements are checked in ledger reconciliation testing.
Cadence and handover. Suites rerun for each kernel or firmware update, each new card network rules edition, and each device approaching a firmware expiry date in the matrix. Suites live in your repository, and the matrix and traces go to your shared evidence folder. Your team owns the devices, key injection, the terminal management system, the acquirer relationship, and the release decision.
Sample deliverable
Sample, synthetic data
| Connector | Happy path | Timeout and retry | Expired consent or token | Duplicate, out-of-order, or offline delivery | Coverage status and open defect |
|---|---|---|---|---|---|
| Bank connector 01 (Berlin Group NextGenPSD2) | Covered, 9 of 9 cases passed: POST /v1/consents reaches consentStatus valid after SCA, and the accounts, balances, and transactions calls return 200 for that consent | Covered, 6 of 6 cases passed: a timed-out transactions call is retried with a new X-Request-ID, and a 429 ACCESS_EXCEEDED response stops refreshes for that consent until the next day | Failed, 4 of 5 cases passed: after a 401 CONSENT_EXPIRED response, the connector keeps scheduling refreshes and shows a stale balance of 1,240.00 XTS as current | Covered, 5 of 5 cases passed: a pending transaction that returns with bookingStatus booked and a new transactionId replaces the pending entry, and overlapping dateFrom windows import no duplicates | Failed, retest scheduled after the INT-0203 fix. INT-0203 (medium): the bank connector does not set reconnect required after a 401 CONSENT_EXPIRED response |
| Bank feed 03 (OFX) | Covered, 7 of 7 cases passed: a STMTRQ for a checking account returns STMTRS with SONRS STATUS code 0, and each STMTTRN posts once to the ledger bank account | Covered, 4 of 4 cases passed: a statement request retried after a timeout reuses its TRNUID, and status 2019 Duplicate request is handled as already processed | Covered, 3 of 3 cases passed: SONRS status 15500 Signon invalid stops the bank feed and asks the user to reconnect, with no empty statement imported | Failed, 5 of 6 cases passed: overlapping DTSTART and DTEND windows repeat FITID values, and one repeated FITID with a changed TRNAMT imports as a second transaction | Failed, retest scheduled after the INT-0221 fix. INT-0221 (medium): a repeated FITID with a changed TRNAMT of 18.75 XTS imports as a second bank transaction |
| Card terminal SDK (offline mode) | Covered, 12 of 12 cases passed: online EMV contact and contactless sales return tag 8A value 00, and each approved sale posts one capture | Covered, 6 of 6 cases passed: an authorisation request with no host response before the timeout sends a reversal before the sale is retried | Covered, 4 of 4 cases passed: a terminal session token that expires while the terminal is offline is refreshed before the store-and-forward upload starts | Failed, 10 of 11 cases passed: offline sales under the terminal floor limit (tag 9F1B) complete with tag 8A value Y3, and one retried store-and-forward upload posts two captures | Blocked for release until the INT-0214 fix passes retest. INT-0214 (high): a store-and-forward upload retried after a lost acknowledgement captures one 42.50 XTS sale twice |
| Broker API A (FIX 4.4) | Covered, 10 of 10 cases passed: Logon (35=A) succeeds, and each ExecutionReport (35=8) with ExecType (150) F updates the imported position once | Covered, 5 of 5 cases passed: no inbound message within HeartBtInt (108) triggers a TestRequest (35=1), and a reconnect resumes at the next expected MsgSeqNum (34) | Covered, 3 of 3 cases passed: a Logon with an expired Password (554) is answered with Logout (35=5) and Text (58), and the broker link shows as disconnected with positions kept | Covered, 8 of 8 cases passed: a MsgSeqNum (34) gap triggers ResendRequest (35=2), and a resent ExecutionReport with PossDupFlag (43) Y and a known ExecID (17) is not counted as a second fill | Covered, with no open defects on Broker API A |
| Payout partner B (ISO 20022 pacs.008) | Covered, 8 of 8 cases passed: a pacs.008.001.08 credit transfer with a UETR returns pacs.002 TxSts ACSP and then ACSC, and the payout is marked settled once | Failed, 5 of 6 cases passed: a timed-out pacs.008 submission is followed by a pacs.028 status request, but one retry is sent as a new pacs.008 with a new UETR | Covered, 4 of 4 cases passed: a payout submitted with an expired API access token returns 401, and the token is refreshed before one resubmission with the same UETR | Covered, 6 of 6 cases passed: a pacs.002 TxSts RJCT after ACSP releases the payout hold once, and a repeated pacs.002 for the same UETR changes no balance | Blocked for release until the INT-0230 fix passes retest. INT-0230 (high): a pacs.008 retried after a timeout carries a new UETR and pays 250.00 XTS twice to one beneficiary |
Amounts use XTS, the ISO 4217 code reserved for testing. Connectors, banks, and partners are generic sandbox endpoints, and terminal sales use scheme test cards masked to BIN and last four.
Questions
What is EMV certification?
How do I get EMV certified?
What is store and forward?
Scope your POS device testing
Send your terminal models, firmware and kernel versions, SoftPOS set-up, and batch close schedule, and we return a test scope for the four deliverables.
Scope your testing