Accepting Global Payments: Local Methods by Market

Three distinct decisions get collapsed into "do you support EUR?", and separating them prevents most of the confusion:

• Presentment — the currency the customer sees. Showing a price in a currency they do not think in costs conversions before the payment is even attempted.
• Processing — the currency the provider will actually accept. A provider that cannot process the currency you are charging in will decline, and that decline looks to your logs like a card problem.
• Settlement — the currency that arrives in your account, and the spread applied to get there. This is priced by the provider, and it is where the real cost of cross-border sits.

Worth being exact about the division of labour here: an orchestration layer decides which provider handles a payment in a given currency. It does not perform the conversion — the provider or the customer's bank does, on their terms. So when you compare providers on cross-border cost, you are comparing their spreads, and no layer above them changes that number.

The failure this causes at checkout has its own page: why your checkout says "payment method not available for your currency".

A cross-border card transaction is scrutinised harder than a domestic one by everyone in the chain. The same card, the same customer and the same amount can be approved locally and refused when presented from abroad, and none of that shows up as an error you would investigate — it arrives as an ordinary decline.

Which makes local acquiring a revenue decision rather than a coverage one. Presenting a payment through a provider that acquires locally in the customer's market is the single change that most reliably moves the number, and it is the mechanism behind most of improving your approval rate.

The reason no single processor is strong everywhere is structural rather than a matter of effort. Domestic payment methods are built on domestic infrastructure — a national bank-transfer scheme, a mobile-money network, a local card scheme — and access to that infrastructure generally requires a local entity, local licensing, and a relationship with local banks. A provider that has done that work in one country has done a large amount of work that transfers nowhere.

So global providers do the sensible thing and reach these methods through partners. That works, and it also explains what you observe in practice: the method appears in the list, but the settlement is slower, the fee is higher, the failure modes are less well documented, and support escalations take longer because a second company is involved. It is genuinely available. It is not the same as a direct connection, and on a large volume in that market the difference is measurable.

The practical consequence is that "does provider X support country Y" is the wrong question. Nearly every large provider will say yes. The questions that separate them are which methods they support there, whether they settle in the local currency or convert, whether the connection is direct or through a partner, and what their approval rate looks like on your own traffic — a number you can only get by sending some.

The reason most companies expand slower than their demand does is that each new market has historically cost an integration. Evaluate providers, sign a contract, get underwritten, build the integration, learn a new webhook format, add a new reconciliation source, and keep all of it working through every future change to your billing system. Repeated per country, this is a permanent tax on expansion, and it is why teams end up serving a market badly for a year because doing it properly never reaches the top of the backlog.

The alternative is to pay the integration cost once, against a layer, and let each additional provider be configuration behind it. The contracts and the underwriting do not disappear — those are between you and each provider, and they still take the time they take. What disappears is the engineering work per provider, and with it the reason the decision keeps getting deferred.

That changes who makes the call. Deciding to accept a local method stops being a release-planning question and becomes an operational one, which matters because entering a market is a commercial decision made on commercial timing. The same shift is what makes a second provider viable as insurance rather than as a project — the argument in how failover is actually built, and one of the jobs described in what payment infrastructure has to do.

"Local payment methods" is used as though it names one thing. It names at least four, and they behave differently enough that treating them alike produces a checkout that technically works and practically does not.

Bank redirects. The customer is sent to their own bank, authenticates there, and approves the transfer. iDEAL in the Netherlands and Bizum in Spain work this way. They are typically irreversible once completed, which removes chargeback risk, and they carry no stored credential — so nothing about them supports an unattended renewal later. A subscription business needs to know that before designing around them.

Wallets. A balance or stored instrument the customer already trusts, often with app-based authentication. Conversion is usually strong because the customer never types a card number, and the wallet may itself be funded by a card or a bank account — which means the underlying decline reasons belong to somebody else.

Mobile money. A phone-number-addressed balance, dominant across large parts of Africa and South Asia, and frequently the primary account rather than a secondary one. For a meaningful share of these customers there is no card to fall back to, so accepting cards is not a partial answer — it is no answer.

Domestic card schemes. Cards that look like cards and are not routed like them. They may not be reachable through international acquiring at all, which is how a market can appear to have high card penetration and still convert badly for you.

The design consequence is that the question is never only whether you can accept a method. It is also whether it settles in a currency you want, whether it supports refunds through the same channel, and whether it can be charged again without the customer present. Those answers vary by category, and the third one decides whether a method can carry a subscription at all.

Adding a market is usually discussed as an integration problem. The integration is the short part. Four operational things change at the same time, and each is easier to plan for than to discover.

Refunds stop being symmetric. A card refund returns along the path the payment took. Several local methods do not support that, and the refund becomes a bank transfer requiring details you never collected. Decide how support will handle it before the first request rather than during it.

Settlement timing diverges. Different methods and different providers pay out on different schedules and sometimes in different currencies. Finance now reconciles several rhythms rather than one, which is a real cost even when every payment succeeds.

Support receives questions it cannot answer. A customer reporting that their bank app says pending is asking about a scheme your team has never used. A short internal note per method — what the customer sees, how long it takes, what pending means — prevents most of those escalations.

Pending becomes a real state. Bank transfers and several local methods confirm asynchronously, sometimes hours later. A system that models only success and failure will either release goods too early or treat a normal delay as a failure. That state, and the one that is genuinely dangerous, are covered in what payment infrastructure has to do.

Some industries hit all of this earlier than others. Infrastructure sells across borders from day one and bills on renewal, which combines the currency problem with the unattended-charge problem — hosting companies going global covers what changes when both arrive together.

Expanding market by market beats enabling everything, and it is measurable at each step.

1. Find where you are already losing. Look at checkout abandonment and decline rate by country. The markets worth fixing are the ones with traffic and no conversions.
2. Name the method, not the provider. Decide that you need UPI, or instant EFT, or mobile money. Then pick a provider because it offers that, rather than picking a provider and discovering what it offers.
3. Check the entity requirement early. Whether a foreign merchant can offer that method at all is a business question with a long answer, and it should not surface after the integration work.
4. Enable, then measure that country alone. Aggregate numbers hide a market-specific win completely.
5. Repeat for the next market. Not all of them at once — each addition should have a reason you could state.

PaymentHood is what makes step five cheap. Your checkout integrates once, and 30+ providers — global, regional and crypto — sit behind it, so entering a market means enabling a provider and writing a routing rule rather than commissioning another integration. Payments are routed by currency, so the customer is put in front of a provider that can actually process what you are charging.

Every provider account stays contracted in your own name, and funds settle directly from that provider to you — PaymentHood is not a processor, an acquirer or a merchant of record, takes no percentage and no per-transaction fee, and never holds your money. If a provider you need is not in the directory yet, we integrate it at no cost.