Scaling in-store payments across countries means an ISO, PSP or PayFac must certify each terminal model per acquirer, per payment application and per country before its merchants can accept cards there. The work covers acquirer eligibility, fiscal and receipt rules, device certifications, acquisition models and the end-of-day messages finance teams need to reconcile.
A payment platform that works in one country rarely travels as is. The moment an operator opens a second market for its merchants, small technical details turn into blockers: a terminal model that runs in France refuses to activate in the UK, a refund flow that worked yesterday does not show up in today's settlement file, store teams are stuck and the program manager cannot see why. This article, updated in October 2026, covers the operational layer that rarely appears in pitch decks: what a terminal depends on, which local rules apply, who controls the software, how long certification takes, how terminals are acquired, what they must send back, and how to curate the catalog store teams pick from. The stakes are not small: according to the ECB payments statistics for the second half of 2024, the euro area counted around 20.7 million POS terminals and 44.3 billion card payments in six months, 81 percent of in-person card payments being contactless.
Why is a payment terminal never just a terminal?
A terminal is the visible end of a chain, and every link in that chain is certified separately: the acquirer and its certifications, the payment application running on the device, and the host platform that manages the integration. The same Android device can be fully certified with one acquirer in France and fail to boot with another acquirer in the UK, because the approval sits on the combination, not on the hardware.
That is why the question an operator should ask before entering a country is not "which terminal should our merchants use?" but "which acquirer, in which country, with which activation model and which embedded application?". On a white-label platform that unifies in-store and online payments, those combinations are what the operator configures once and then offers to every merchant in that market.
Which local constraints block an in-store rollout in a new country?
Each country adds its own rules on top of scheme certification, and most of them concern the receipt and the fiscal record rather than the card itself. In Italy, payment terminals must be linked to the merchant's telematic cash register: under Law 207/2024 and the Revenue Agency provision of October 31, 2025, every POS activated from January 1, 2026 has to be registered against the cash register's serial number so that payment data is recorded transaction by transaction and transmitted daily. In Germany, electronic cash registers must carry a certified technical security device (TSE) under the KassenSichV, and a draft published in October 2026 would make electronic registers and digital receipts mandatory for businesses above 100,000 euros of turnover from January 1, 2028.
Add the acquirers that are eligible in each market, the local schemes and wallets that only work at home, and the device approvals themselves: EMVCo type approval for the contact and contactless kernels, and PCI PTS POI approval for PIN and card data protection, both evaluated by recognized laboratories and listed per device version. An expansion playbook should map, country by country, the mandatory acquirers, the accepted schemes, the tax and receipt regulations and the device certifications, before the first store is opened. The #PayWorldTour guides cover the local payment landscape of the main European markets.
Who controls the software running on the terminal?
In most deployments, nobody on the operator's side knows which version of which application is running inside the terminals, because the application is vendor-managed. That model keeps maintenance off the operator's plate, but it creates a strong dependency: the operator cannot push changes, cannot debug on the device, and every new feature waits for someone else's roadmap.
The dependency also applies to flows. A terminal that works for a plain sale in one country does not necessarily support refunds, pre-authorizations or fallback handling there, and each flow must be certified per terminal, per application and per acquirer. For an ISO or PayFac, the practical consequence is that the terminal catalog has to record not only the model but the application version and the certified flows behind it.
How long does it take to certify a new Android terminal?
Onboarding a new terminal model is a project, not a plug-and-play step. In our experience, enabling a new Android device with an acquirer takes from several weeks to a few months, because it requires internal testing, scheme certifications and acquirer validations in sequence, and most providers will not start that work without a business case behind it.
This is why a short, fully certified catalog beats a long, partially supported one. Three terminal models certified for every flow and every acquirer a merchant base needs will serve store teams better than seven models that each work in some countries with some acquirers.
Should merchants buy, rent or activate terminals, and why does it matter to the operator?
A terminal is a contract as much as hardware, and the acquisition model changes the cost structure, the lifecycle, the support channels and the finance reconciliation for the merchant and for the operator serving it. Merchants may buy the device (capital expenditure plus a support contract), rent it (monthly fee and renewal terms) or activate it as SoftPOS on a commercial smartphone, with no dedicated hardware at all.
Whatever the model, the operator should track not only which terminal a merchant uses but how it was acquired, because that determines the escalation path when something breaks: a rented device goes back to the lessor, a purchased one to the manufacturer's support, a SoftPOS activation to the application provider.
What must a terminal send for reconciliation and disputes?
Not all terminals speak the same language, and what a terminal sends back matters more than what it prints. A terminal fit for a multi-country program must send proper end-of-day messages, support tokenization, handle fallback cleanly and log the key events a risk team needs to investigate a dispute. When those messages are missing, finance teams cannot reconcile, risk teams cannot investigate and customers face silent errors.
On the platform side, this is where in-store and online flows should converge: every terminal event lands in the same transaction record as the online payments, so the operator's reconciliation and settlement works per merchant, per store and per acquirer without a separate POS export. The Matcher article describes how terminal receipts are matched to acquirer settlements. The question to ask every terminal vendor stays the same: what does this device send, and where does it go?
How should an operator curate its terminal and acquirer catalog for store teams?
Store staff cannot be left to decide which terminal works with which acquirer in which country, so the POS catalog an operator exposes to its merchants must be curated: a shortlist of tested terminal and acquirer combinations, deployment documentation included, lifecycle and support rules defined, and consistent pricing. It is not a marketplace. It is a controlled distribution layer.
The same discipline applies to the rollout itself. Launching ten countries in one quarter rarely works; an in-store MVP does: two or three certified Android terminals, one or two acquirers, the sale, refund and end-of-day flows defined, and one dashboard shared by program managers and store teams. Once that works in two markets, the operator can expand into new markets by adding acquirers and devices to a model that already reconciles, which is what omnichannel coverage means in practice for a PSP or ISO: fewer terminal models, tighter supplier coordination, visibility into what runs inside the box, and a clear list of constraints per country.
Sources
- European Central Bank, "Payments statistics: second half of 2024", July 2025
- Baker Tilly Italy, on Agenzia delle Entrate provision 424470 of October 31, 2025 (POS to telematic register link from January 1, 2026)
- Fiscal Solutions, "Germany: Mandatory Electronic Cash Registers and Digital Receipts Proposed from 2028", October 2026
- PCI Security Standards Council, PTS Point of Interaction (POI) standard
- EMVCo, acceptance device approval processes
_%2520a%2520game%2520changer%2520for%2520digital%2520transactions_-Cover.webp){kind=spacer}
