Rolling out in-store payment acceptance internationally. 7 chapters and a final quiz.

Chapter 1. Qualifying a country and settling the architecture.

A retailer entering a new country rarely orders the right terminal the first time. The problem is the order of decisions, not the technology. Hardware comes last. Before it come three questions whose answers sit with third parties: which instrument actually carries in-person payments, which intermediation layer is mandatory, and which local obligations apply to the terminal. This chapter produces one document, the country acceptance sheet: one page, eight rows, each with its source.

Four architectures and how to choose between them

Chapter 2. Writing the approval clauses of a tender.

A payment terminal is a cryptographic vault that must pass three separate approval gates, granted by three authorities on three timelines. The question you put to suppliers determines the quality of the answers. Asking whether the terminal is certified invites a yes that commits to nothing; the right wording names the standard, the country, and the date. A usable answer fits in a table, not a brochure.

Six requirements to spell out in writing

• One row per model AND per country. A table with a single row per model hides exactly what you are looking for: the missing approval in the third market.
• An expiration date for each approval, not a checked box. The date sets the ordering window, and therefore the fleet renewal schedule.
• The PCI PTS POI approval number, verifiable on the PCI Security Standards Council's public list. A number can be cross-checked; a logo in a brochure cannot.
• The radio technologies supported: ISO/IEC 14443 Type A and Type B, plus FeliCa where the market requires it. Japan and Hong Kong fall on this row.
• The register communication protocol, named and versioned. This row determines the integration workload in chapter 5.
• The key injection method: at the factory, on site, or remotely. On-site injection across 300 stores is a logistics project, not a formality.

model: <commercial name>
country: <ISO 3166-1 alpha-2>

pci_pts_poi:
  approved_version: <6.x | 7.0>
  approval_number: <number on the PCI SSC public list>
  expiration: <YYYY-MM-DD>        # a date, never "yes"

emv:
  level_1: { certificate: <number>, expiration: <YYYY-MM-DD> }
  level_2: { kernel: <name + version>, expiration: <YYYY-MM-DD> }
  level_3: { acquirer: <name>, country: <ISO2>, test_date: <YYYY-MM-DD> }

national_approval:
  standard: <Ashrait (Shva) | CB 6.0 (GIE CB) | FeliCa approval | ...>
  status: <obtained | under review | not requested>
  expiration: <YYYY-MM-DD>

radio:
  iso_14443: [A, B]
  felica: <yes | no>

register_protocol: <nexo Retailer Protocol | ZVT | proprietary: name + version>
key_injection: <factory | on site | remote>

Chapter 3. Configuring contactless and diagnosing declines.

The contactless radio layer is the same everywhere: ISO/IEC 14443 for the physical layer and one EMV contactless kernel per accepted network. What varies from country to country is the amount above which cardholder verification becomes mandatory, and the authority that sets it. That source determines how quickly the limit changes, since a scheme limit moves within months. A regulatory limit takes years. The payments team of a multi-country retailer therefore keeps a table and dates every row.

Three terminal parameters turn this regime into behavior at the register. The kernel list that is enabled determines which cards are read, network by network. The CVM list ranks the accepted verification methods and the amounts at which they switch. The floor limit sets the amount above which online authorization becomes mandatory. These three settings come with the acquirer's configuration, and they are checked when the first store goes live, never after the hundredth.

• Write the checkout instructions in the local language, with the local limit and its exact wording. A sales associate who explains a PIN request correctly prevents a customer incident.
• Prohibit manual entry of the card number when the reader fails. It is a fallback flow that carries costly liability, and some local standards refuse it.
• Track the magstripe fallback rate, terminal by terminal. A sustained rise on one terminal signals a worn chip reader before it fails.
• Check offline capability where the business requires it. BankAxept works offline in Norway and serves as the designated arrangement for cash distribution in stores (Norges Bank, December 2025).
• Check domestic routing where it is mandated. In Malaysia, MyDebit requires priority domestic routing of debit transactions (PayNet).

Chapter 4. Choosing between terminal, SoftPOS, and QR.

SoftPOS turns an ordinary phone into a contactless acceptance point with no extra hardware. Its security framework is PCI MPoC, published in 2022 by the PCI Security Standards Council, which consolidates SPoC for PIN entry and CPoC for contactless. The best-known implementation is Tap to Pay on iPhone, available in more than 80 countries and territories (Apple, developer.apple.com/tap-to-pay/regions, accessed August 2026). The service requires a certified payment provider as the integration point. Check that country list before making the call, not after.

• Check that the service is available in the country on the vendor's own page, before any cost analysis. The gaps are not delays: these are markets built around something other than card contactless.
• Check that the certified provider covers the country. The service and the provider are two separate conditions, and they do not overlap everywhere.
• Inventory the staff phone fleet, model by model and OS version by OS version. A mixed Android fleet produces inconsistent contactless behavior.
• Measure the share of contactless cards among your actual customers, not the national figure. International customers carry older cards.
• Check local obligations for the acceptance point. In Italy, software solutions on phones fall within the same tax pairing scope as terminals.

Chapter 5. Wiring the register without redoing the project in every country.

Below the terminal, the authorization message is still ISO 8583 in most markets. Above the terminal, standardization ends. The dialogue between register software and terminal is national, sometimes proprietary, often legacy. That makes it the most expensive layer of a multi-country rollout, and the one specifications forget. The approach taught here is to isolate that layer behind a single contract, then estimate the rest in flows to test.

nexo: the only attempt at a standard above the terminal

The nexo standards association publishes acceptance protocols based on ISO 20022, three of which directly concern a retailer. The nexo Retailer Protocol standardizes the dialogue between the register and the point of interaction, under the name Sale to POI. The nexo Acquirer Protocol carries messages to the acquirer in the caaa message family. The nexo TMS Protocol governs fleet management, in the catm family (nexo standards, accessed August 2026). Adoption is driven by national standards rather than by the market. In France, the CB 6.0 standard, known as FRV6, builds on these protocols and has been mandatory for new terminals since January 1, 2025 (GIE Cartes Bancaires).

{
  "operation": "sale",
  "sale_reference": "TCK-2026-000418",
  "amount": { "value": 4990, "currency": "EUR", "exponent": 2 },
  "tip": { "allowed": true, "entry": "terminal" },
  "point_of_sale": { "store": "PT-LIS-004", "register": "03", "tid": "12345678" },
  "expected": [
    "status",
    "payment_method",
    "masked_pan",
    "aid",
    "authorization_reference",
    "cvm_mode",
    "batch_number"
  ]
}

• The amount travels in the currency's minor unit, with its exponent. A currency with no decimals is written without multiplying by 100.
• The batch number comes back in the response. Without it, the reconciliation in chapter 6 cannot be automated.
• So does the verification method. It explains after the fact why a cardholder entered a PIN, and it defuses complaints.
• A per-country adapter translates this contract in a single module, tested in isolation. The rest of the register software knows nothing about the local protocol.
• No business rules in the adapter. An adapter that makes decisions ends up duplicated, then divergent, then wrong in one country out of three.

Chapter 6. Tracking batch upload, settlement, and reconciliation.

An authorization is not a payment. It reserves an amount with the issuer, nothing more. Money flows to the retailer only after the batch of transactions is submitted to the acquirer: the end-of-day batch upload, which runs at a fixed time set by a terminal parameter. A transaction that is authorized but never submitted is never paid. The corresponding check is a single daily query, yet most rollouts do without it.

• One merchant ID per country and per legal entity, never shared across two countries. A shared MID makes the third reconciliation impossible to untangle.
• A terminal with no batch upload for 24 hours triggers an alert. It is the only check that protects against silently lost revenue.
• The settlement currency is written into the acquiring contract. Collecting in local currency and being settled in the head-office currency hands the FX margin to the acquirer.
• Dynamic currency conversion offered to the cardholder creates a separate revenue line and a risk of complaints. Manage it actively; do not enable it by default.
• Keep deposit files at least as long as the dispute window that applies in the country. A dispute without the deposit record is lost from the start.

Chapter 7. Managing the fleet, after-sales service, and local deadlines.

A terminal fleet is managed like reference data, not like inventory: each unit carries an identifier, a software version, a configuration, a dated approval, and a point of sale. These attributes drift over time, so a retailer that ignores them discovers the gaps through declines, penalties, or service outages. Six indicators are enough to keep the whole fleet under control. Each one must be tied to an action; otherwise it is useless.

• Terminal ID (TID) and merchant ID (MID), linked to the point of sale and to the country's legal entity.
• Serial number and model, the only data that link a terminal to its approval and its expiration date.
• Software version and configuration version, collected automatically, never entered by hand.
• Regulatory pairing reference, where the country requires one, with the date it was obtained.
• Key injection date and injection method, which determine the emergency replacement procedure.
• Service status and date of last communication, the basis for the batch upload alert and for managing after-sales service.