Most international expansion projects treat payments as a late-stage detail. For example, the ERP rollout gets the attention. Localisation, tax and logistics get plans. Meanwhile payments gets a line that reads "existing gateway supports multi-currency," and everyone moves on.
That line is usually wrong. Multi-currency is not the same as multi-method. So a merchant can happily charge a customer in Brazilian real and still fail to reach most Brazilian buyers.
This is a practitioner's look at what local payment methods actually require, why the integration-per-country model breaks down, and what it means for .
The assumption that fails first
In North America and much of Western Europe, cards cover most consumers. Therefore a card gateway looks like sufficient global infrastructure, and your existing feels like enough.
Elsewhere, however, that assumption collapses. Brazil runs heavily on PIX, an instant central-bank rail that no card network touches. Mexico runs on OXXO cash vouchers and SPEI transfers. India runs on UPI. Japan and South Korea are wallet-fragmented, each with six or more meaningful consumer wallets. Indonesia has a national QR standard.
None of these are cards. Consequently your acquirer cannot reach them, however competitive your rates.
The result is not a slightly smaller audience. It is a checkout that a large share of local buyers cannot complete at all.
What each region actually expects
| Region | Methods that matter | Type |
|---|---|---|
| Brazil | PIX, Boleto, PicPay, NuPay, MercadoPago | Instant rail, cash voucher, wallets |
| Mexico | OXXO, SPEI, CoDi, Pay Cash | Cash voucher, bank transfer, QR |
| Colombia | PSE, Nequi, Daviplata, Efecty | Bank transfer, wallets, cash |
| Argentina | Rapipago, Pago Fácil, Cobro Express | Cash networks |
| Peru | Yape, PagoEfectivo, BCP | Wallet, voucher, bank |
| Chile | WebPay, Khipu, Servipag, Sencillito | Gateway, bank transfer, cash |
| India | UPI | Instant bank rail |
| Japan | PayPay, Rakuten Pay, au PAY, d Barai, Merpay, LINE Pay, Konbini | Wallets, convenience-store cash |
| South Korea | Kakao Pay, Naver Pay, TOSS, Payco, SSGPAY | Wallets |
| China | Alipay, WeChat Pay | Super-app wallets |
| Southeast Asia | QRIS, DANA, PromptPay, TrueMoney, Touch 'n Go, DuitNow, ZaloPay, MoMo | QR standards, wallets |
| Australia | NPP | Instant bank transfer |
Two patterns stand out. First, several markets run on national rails rather than commercial products, so coverage is close to universal there. Second, cash-based voucher payment remains significant across Latin America and Japan, which surprises teams who assume cash is disappearing.
For market detail, SensePass publishes country guides to , , the and . Global wallets sit alongside them, and the full shows how the categories fit together.
The integration-per-country trap
Faced with this, the default plan is to integrate a local PSP per market. At first, that works. But it scales badly.
Each market adds a contract, an API, a settlement format, and a reconciliation process. Each one then needs maintaining as the provider changes. So three markets stays manageable. Meanwhile eight becomes a permanent workstream.
Consequently most Dynamics 365 merchants stall. They launch a new country with cards only, watch conversion under-perform, and defer the fix. Meanwhile the finance team accumulates a different settlement feed for every market that did get built.
What a connector changes
A payment connector inverts the model. Rather than integrating each market into your ERP, you connect Dynamics 365 once to a layer that already maintains those local provider relationships.
works this way. One integration links , or to 112 payment methods and 50+ processors. The local methods in the table above are already built in.
Three consequences matter for an implementation.
Adding a market becomes configuration. You integrate once, then enable methods per country. Nothing changes inside the D365 environment, and no per-market development applies.
You skip assembling an acquirer stack per country. The connector stays and already connects regional acquirers. Therefore market entry does not begin with a payments procurement exercise.
Everything reconciles into one ledger. Local confirmations and settlements post back into Dynamics 365 automatically. As a result, finance is not importing a separate country feed for each market.
Channels matter as much as markets
International expansion rarely stays online-only. So the same question applies to how you sell, not just where.
An advanced setup covers each channel from the same integration. Online checkout is the obvious one. In stores, lets a customer tap their own phone and pay with a local wallet, with no app download and no dedicated terminal. For invoices, quotes and phone orders, carries every enabled method rather than cards alone.
That consistency matters more abroad than at home. After all, a shopper who uses a local wallet online will expect it at your counter too.
The operational detail most projects miss
Local methods do not just add tenders. Some of them change your order flow, and that is where ERP projects get caught.
Voucher payments are the clearest case in practice. With OXXO, Boleto or Konbini, the customer completes checkout, receives a reference, and pays cash at a store afterwards — sometimes days later. Therefore the order sits unpaid in the meantime.
That forces four decisions before launch. Do you reserve stock while a voucher is open? How long does a voucher stay valid? What order status unambiguously means "awaiting payment," so nobody ships early? And what happens automatically when a voucher expires?
Get those wrong and you either oversell inventory or ship goods nobody paid for. covers the full flow, including the accounting treatment.
Instant rails create the opposite situation. PIX and UPI confirm in seconds, so orders can release almost immediately. Consequently your fulfilment process may need to handle a faster cycle than card capture allows.
Reconciliation across markets
A few principles keep multi-market payments manageable.
Post local settlements through a clearing account rather than straight to bank, particularly where the provider settles in batches. Then clear to bank when the actual payout arrives, so your bank reconciliation matches the statement line. The same pattern applies to deferred methods generally, and the works through it step by step.
Post collection fees separately rather than netting them into the deposit. Otherwise you lose visibility into cost per order by market, which is exactly the number you need when deciding where to expand next.
Apply the transaction-date rate at the sale and the settlement-date rate at the payout, then post the difference to realised gain or loss. For multi-entity structures, keep a clearing account per legal entity. covers multi-entity and multi-currency handling in more depth.
Finally, report by tender and by market. Local preference shifts quickly, so the data should drive where you widen coverage. Where collections are the constraint rather than acceptance, is the related problem worth solving alongside.
A scoping checklist
Useful questions before committing to an approach:
- Which two or three methods dominate each target market?
- Does the route require a local entity or acquirer relationship per country?
- How many markets do you expect to enter within three years?
- Who maintains each integration when a local provider changes its API?
- Do any target markets rely on cash vouchers, and does your order flow handle delayed payment?
- Where does settlement data land, and who reconciles it?
- Can you add a market without a development project?
If you are entering one market and staying there, a local PSP integration is perfectly reasonable. But if the roadmap names several, evaluate a connector before you build the first one.
Frequently asked questions
Does multi-currency support mean I can sell anywhere? No. Multi-currency lets you price and settle in local currency. However, it does not give you local payment methods, and in many markets those methods carry the majority of consumer volume.
Can Dynamics 365 accept PIX, OXXO or UPI natively? No. None of them runs on card rails, so each requires either a local provider integration or a that already supports it.
How many local methods should I enable per market? Usually the two or three that dominate locally. Full coverage is unnecessary, but missing the dominant method costs conversion immediately.
Do cash voucher payments still matter? Yes, considerably, across much of Latin America and in Japan. They reach buyers who hold no card at all.
How do local methods affect fulfilment? Instant rails confirm in seconds and release orders quickly. Voucher methods pay after checkout, so orders must wait in an explicit "awaiting payment" status.
Will local methods reconcile inside Dynamics 365? Through a connector, yes. Confirmations and settlements post back automatically, so finance works from one ledger rather than a feed per country.
Which Dynamics 365 modules does this apply to? Business Central, Finance & Operations, and Commerce. A connector sits alongside the environment rather than inside it.
SensePass is a payment gateway and connector for Microsoft Dynamics 365. It links Business Central, Finance & Operations, and Commerce to 112 payment methods and 50+ processors through a single integration, with tap-and-pay, pay by link and surcharging built on top. or .