Infrastructure and regtechLicence required

POS terminal and SoftPOS testing

FintechAssuranceLabs engineers test POS and merchant services platforms, the category of products like Square, Toast, and SumUp. POS testing covers card terminals and SoftPOS apps, offline store-and-forward, tips and partial authorisations, split tender, chip fallback, and end-of-day batch close, with evidence that a sponsor acquirer, a card network, or a payment regulator can review.

What breaks at the terminal, in offline mode, and at batch close

A POS provider earns on hardware, a software subscription, and a take rate on card sales, and the merchant receives each card sale minus that take rate. Card network rules below come from the Visa Core Rules and Visa Product and Service Rules, edition of 18 April 2026. All sources were checked on 2026-09-16.

Offline queue replayed after the authorisation window. A terminal or SoftPOS app stores card sales while offline, and the upload omits the deferred authorisation indicator or waits out a weekend with the device switched off. Visa section 5.7.3.3 requires such a sale to carry the indicator and to be authorised within 24 hours of the transaction date for all merchant category codes (MCCs) except three transit codes (4 days) and two Danish codes (7 days after a connectivity issue outside the merchant's control). Declined sales pay nothing and earn no take rate, and a sale without a valid authorisation can be disputed under condition 11.3, No Authorization/Late Presentment.
Tip adjusted past the permitted variation. Above the floor limit, Visa section 7.5.6 lets the clearing amount exceed the authorisation amount only within Table 7-10: since 21 February 2026, up to 30% for US caterers and restaurants (MCCs 5811, 5812, 5814) and up to 20% for restaurants (MCCs 5812, 5814) in the AP, Canada, CEMEA, Europe, and LAC regions. The amounts must always match after a partial authorisation and for a European Economic Area (EEA) transaction. A tip-adjust job that applies the US variation to an EEA sale clears more than was authorised, and the issuer can dispute the unauthorised amount under condition 11.3. In the US, a tip-out report that deducts more than the card fee percentage exceeds the Department of Labor's Fact Sheet #15 limit and exposes the merchant under 29 U.S.C. 216(b) to the tips unlawfully kept plus equal liquidated damages.
Split tender left open or charged twice. A prepaid card is partially approved, the second card declines, the customer leaves, and the POS never reverses the partial approval. Visa section 7.3.9.1 requires the acquirer to ensure that participating merchants submit a reversal when the cardholder does not complete the purchase and clear no more than the partially approved amount. When a customer switches to cash after card approval and the POS keeps the card sale, Visa's Dispute Management Guidelines (June 2024) tell the merchant to accept a condition 12.6.2, Paid by Other Means, dispute, so the card amount comes back out of the merchant's payout.
Chip read failure sent without fallback values. After a chip read error, the terminal completes the sale from the magnetic stripe without the values that identify a fallback transaction. For a Visa chip card, section 5.8.2.2 makes a fallback transaction the acquirer's liability when the issuer did not authorise it or authorised it without those values. A fraudulent sale of that kind stays the acquirer's loss, and one full sale amount outweighs the take rate on many sales.
Batch left open past the processing window. A terminal is off at the scheduled close, or the close job runs in the provider's home time zone, so approved sales stay out of clearing. Visa section 5.7.3.5 allows 5 calendar days from a valid authorisation for most card-present transactions (Table 5-12) and 2 calendar days from the transaction date for Europe Region intraregional contactless transactions, other than mobility and transport. Late sales can be disputed under condition 11.3, and until the batch closes the merchant is unpaid and the take rate uncollected.

Licence flag and the evidence acquirers and regulators ask for

POS and merchant services carry licence flag "yes": a POS provider that signs merchants or receives their settlement works as a payment facilitator under a licensed acquirer or holds its own licence; see payment acquiring.

Device evidence comes from PCI Security Standards Council (PCI SSC) programmes in all three jurisdictions. PCI SSC lists each approved PIN Transaction Security (PTS) point of interaction (POI) device by hardware and firmware version, and its bulletin of 6 November 2018 strongly advises acquiring customers to deploy only devices whose fixed version characters match the listing exactly. Firmware approved under PTS POI v6 or higher expires three years after approval, but not after the device approval expires (PCI SSC expiry schedule). For SoftPOS, PCI MPoC v1.1 (26 November 2024) covers PIN and contactless entry on one commercial off-the-shelf (COTS) device. PCI SSC accepts no new SPoC or CPoC submissions after 31 October 2026, and existing listings keep their expiry dates (PCI SSC bulletin, 1 May 2026).

United States

Visa section 5.6.3.1 requires an acquirer that deploys a Tap to Phone solution to register the solution with Visa and obtain approval before launch. The sponsor acquirer asks for:

firmware and hardware version checks per terminal model against the PCI PTS listing;
the MPoC or CPoC listing reference and the Visa Tap to Phone registration per SoftPOS release;
deferred authorisation tests, and tip adjustment tests at the 30% US restaurant limit;
PCI DSS evidence for systems that store, process, or transmit cardholder data.

European Union

Acquiring is a payment service under PSD2 Annex I, point 5. Article 11 of Delegated Regulation (EU) 2018/389 sets the EUR 50, EUR 150 cumulative, and five consecutive payment limits for contactless payments without strong customer authentication; see PSD2 SCA. Beyond those limits, a terminal that cannot switch to chip and PIN loses the sale. Directive (EU) 2019/882 covers payment terminals placed on the market after 28 June 2025, hardware and software (Article 2(1)(b)(i), recital 26); see the EAA requirements. Evidence to prepare:

contactless boundary tests at each Article 11 limit, with the switch to chip and PIN;
accessibility test results for PIN entry, amount, and receipt screens on terminals and SoftPOS;
batch close tests showing intraregional contactless sales in clearing within 2 calendar days.

Canada

The Bank of Canada's case scenarios about point-of-sale terminals (12 December 2023) find that a terminal manufacturer that also provides the payment gateway software to merchants performs initiation and authorisation of electronic funds transfers and needs to register as a payment service provider, assuming it meets the other registration criteria. Supervision under the Retail Payment Activities Act (RPAA) began on 8 September 2025. Section 17(1) requires a risk management and incident response framework, and section 18(1) requires notice without delay to the Bank and to affected end users, payment service providers, and designated clearing houses of an incident with material impact on them; see the RPAA requirements. Evidence to prepare:

a payment function map showing which component initiates and authorises each payment;
terminal fleet outage and offline recovery tests mapped to the section 17 framework;
incident scenarios recording the time from detection to end-user notice.

POS testing checklist

The POS and payment device testing service delivers these as its offline, firmware compatibility, and batch reconciliation deliverables.

Offline and store-and-forward. Connection loss mid-authorisation, a queue that survives reboot, replay order, and the 24-hour deferred authorisation cut-off.
Tips. Tip adjustment at and above each Table 7-10 limit, a tip on a partially approved sale, and tip-out totals against card fees.
Split tender. Partial approval followed by cash, a second card, or a decline, and the reversal when the customer leaves.
Fallback. Chip read failure to magnetic stripe and fallback values in the authorisation message.
SoftPOS. Attestation failure on a rooted phone and on-screen PIN entry.
Hardware and firmware. Displayed firmware version against the PCI listing and a failed over-the-air update.
Cash drawer and inventory sync. Drawer opening on cash tenders only, stock counts after two offline devices sell the same item, and a void that returns stock.
End-of-day batch close. Close with one device offline, merchant time zones, a resent batch that must not clear twice, and batch totals against the settlement file.

Integrations and protocols to cover

Terminal to host. ISO 8583 authorisation, reversal, advice, and batch upload messages with deferred authorisation and partial approval fields.
Payment kernels. EMV contact and contactless kernels and the EMV Level 3 tests that each payment system defines.
SoftPOS stack. MPoC SDKs with attestation and monitoring back ends, platform tap to pay APIs on iOS and Android, and on-screen PIN entry.
Terminal management. Remote key injection, over-the-air updates, and device inventory by serial number.
POS software to terminal. Semi-integrated and cloud terminal APIs for sale, tip, and refund requests, with result webhooks.
Peripherals and back office. Printers, scanners, inventory sync, and payroll tip-out exports.

Standards

Services

Guides

Blog posts

Sample deliverable

Sample, synthetic data

integration coverage reportIntegration coverage report: bank connectors, terminal SDK, broker API, and payout partner

Integration coverage report: bank connectors, terminal SDK, broker API, and payout partner
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 a POS system?

A POS system, or point-of-sale system, is the hardware and software a merchant uses to record sales, take payments, and track stock at the counter or table. A POS system usually combines a sales app on a terminal, tablet, or phone with a card reader, a receipt printer, and a cash drawer, and sends card payments to an acquirer or payment processor for authorisation.

How does a POS system work?

A POS system records the items in a sale, calculates tax and the total, and takes payment by card, cash, or both. For a card payment, the card reader reads the chip, the contactless card, or the phone and sends an authorisation request to the acquirer's processor, which routes the request through the card network to the card issuer. Approved card sales go into a batch that the POS system closes at a set time for clearing and settlement.

What is POS testing?

POS testing checks that point-of-sale hardware and software record each sale once, take each payment in the correct amount, and settle each day's card sales, including when the network connection drops. POS testing covers card reader and chip flows, offline store-and-forward, tips, split tender, refunds, cash drawer and inventory sync, and end-of-day batch close, using test cards instead of real card numbers.

Scope your POS testing

Send your terminal models, SoftPOS setup, processor links, and batch close schedule, and we return a test scope with the evidence your acquirer will ask for.

Scope your testing