Scaling in-store payments across countries: what retailers need to know (but rarely hear about)

If you’re a retailer operating in multiple countries, or planning to open new markets, this article is for you.

You might already have payment systems that work well in one country. But the moment you expand, small technical details turn into blockers. A terminal model that works in France suddenly refuses to activate in the UK. A refund that worked yesterday doesn’t show up today. Local teams are stuck, and HQ can’t understand why.

This guide is about the operational truth of in-store payments. The things that rarely show up in pitch decks, but slow you down every day.

Let’s walk through what actually matters when scaling payment infrastructure across borders.

1. A terminal is not just a terminal

You might use a PAX A920 in France with EMS and be perfectly happy. Try the same device in the UK with Elavon and it might not even boot.

Why? Because terminals aren’t standalone. They depend on:

• the acquirer and their certifications
• the payment app running on the device
• the host platform that manages these integrations

So when expanding into a new country, don’t just ask “Which terminal should we use?”
Ask: “Which acquirer, in which country, with what activation model and what embedded software?”

2. Local constraints are real and often hidden

Regulations vary widely between countries. Some examples:

• In Italy, terminals must issue receipts via certified fiscal printers
• In Germany, only specific acquirers are allowed in certain regions
• Some wallets or cards simply don’t work outside their home market

PCI-DSS compliance is crucial for securing card transactions globally. Ensure all terminals meet these standards to avoid penalties.

Certifications with schemes also take time. Sometimes weeks or months, especially on new Android terminals. Planning ahead is crucial. Your expansion playbook should map, country by country:

• mandatory acquirers
• accepted schemes
• tax and receipt regulations
• device certifications

3. You don’t control what runs on the device

Most retailers have no idea what version of what app is running inside their terminals. It’s usually vendor-managed. Vendor-managed apps can limit your control over updates and features. Plan for these dependencies to avoid operational disruptions.

That can be good for maintenance. But it also creates a strong dependency. You can’t push changes. You can’t debug. And every new feature needs to go through someone else’s roadmap.

Also: just because a terminal works somewhere doesn’t mean it supports all flows. You might need refund, pre-auth, or fallback handling. Each one must be certified per terminal, per app, per acquirer.

4. Deploying a new terminal is a real project

Many assume onboarding a terminal is plug-and-play.
In reality, enabling a new Android device can take 6 to 12 weeks.

Why?

Because it requires:

• internal testing
• scheme certifications
• acquirer validations

No business case, no priority. That’s the rule for most providers. Better to have 3 fully certified models than 7 half-supported ones.

5. Buy, rent or activate: it matters more than you think

A terminal isn’t just hardware. It’s a contract. Each acquisition model impacts cost, lifecycle, and support. Choose wisely to align with your business strategy and needs. You might:

• buy it (capex plus support)
• rent it (monthly cost, renewal terms)
• activate it (SoftPOS, no hardware at all)

Each model has an impact on:

• cost structure
• lifecycle
• support channels
• finance reconciliation

Track not only what terminal is used, but how it was acquired.
This changes the escalation path when something breaks.

6. The terminal is just the start: What matters is what it sends

Not all payment terminals speak the same language. A good terminal doesn’t just beep and print. Ensure terminals support tokenization and detailed logging. This aids in reconciliation and dispute resolution, enhancing operational efficiency. It must:

• send proper end-of-day messages
• support tokenization
• handle fallback cleanly
• log key events for dispute resolution

If these messages are missing, finance teams can’t reconcile
Risk teams can’t investigate
And customers may face silent errors

Always ask: “What does this terminal send, and where does it go?”

7. No store without supplier alignment

Store staff can’t be left alone to decide which terminal works with which acquirer in which country. Provide clear documentation and support rules for terminals. This ensures consistency and reduces errors during deployment. Your POS store, internal or external, must be curated.

Not a long list of random models and options. What works best:

• a shortlist of tested terminal-acquirer combinations
• deployment documentation included
• lifecycle and support rules defined
• clear, consistent pricing

It’s not a marketplace.
It’s a controlled distribution layer.

8. Start with less, scale with confidence

Trying to launch 10 countries in one quarter? Don’t. Focus on a few key markets initially to refine processes. This approach builds a strong foundation for broader expansion. Start with a payment MVP:

• 2 or 3 certified Android terminals
• 1 or 2 acquirers
• flows defined: sale, refund, end of day
• one dashboard for program managers and store teams

Once this works, scale.
Not before.

In summary

In-store payments aren’t just about machines. They’re about compatibility, support, compliance, and reliability. Retailers who plan meticulously will scale faster and more efficiently. Addressing these nuances ensures smoother international growth. When you expand to new countries, each of those layers can break in subtle ways.

To get it right, you need:

• fewer terminal models
• tighter supplier coordination
• more visibility into what runs inside the box
• a clear list of constraints per country

Retailers who manage this well don’t just scale faster. They waste less time fixing issues nobody saw coming.