Explainer: building a merchant payments strategy for global expansion

Milko Filipov, Managing Director at reMonetary, shares how merchants eyeing global expansion should approach their payments strategy. 

When it comes to payments, merchants expanding internationally must decide what to localise and what to standardise. A wrong localisation-standardisation balance can affect the commercial and operational setup of the entire business. 

Selling into a new country is relatively simple if we’re looking only at how to make the payment experience work well; however, scaling that same experience across many markets is not as easy. 

Customers expect to pay in a local currency, use a trusted payment method, and encounter a familiar checkout experience. For that experience, merchants must decide how payments are processed, where funds settle, when currency conversion happens, and how payment data reaches finance, tax, and accounting systems. 

International payments depend on both localisation and standardisation aspects. Some parts of the payment experience need to adapt to the market, while others benefit from centralised management. You shouldn’t aim for a different payment setup for every country, nor one identical configuration everywhere. Your goal is knowing which decisions genuinely need to be local and which can stay part of a common global architecture. 

Start with what customers expect from their ecommerce experience

The first decisions relate to the customers’ shopping experience: available payment methods, pricing currency, and checkout structure. 

Payment preferences differ considerably between markets: cards dominate in some countries, while digital wallets, bank transfers, account-to-account (A2A) payments or Buy Now, Pay Later (BNPL) services matter more in others. Even a single wallet's role can change from one market to another along with the wider financial ecosystem around it. 

The approach to payment methods should not be a checklist of everything locally available. Instead, ask which methods customers actually use and expect, and whether supporting them improves conversion enough to justify the added technical and operational complexity. 

Another part of this decision is how to access the payment methods. A merchant can connect to a payment method directly or through a payment service provider (PSP) – the infrastructure that connects merchants to payment methods, card networks, and acquiring services. While a PSP simplifies the technical setup, you should still analyse coverage market-by-market, as a provider that works well in one country may not offer the same methods, processing capabilities, or economics in another. 

Although currency is also part of the customer experience, there’s an important difference to consider: a merchant can display prices either in the customer's local currency, convert the base price dynamically, or maintain market-specific ones. For a small catalogue, dynamic conversion is straightforward, but it is much harder when thousands of products, promotions, and mixed tax treatments across markets are involved. The merchant also needs a reliable way to determine which currency to show – typically based on the selected market, billing, or shipping address, rather than IP address or browser language. 

Most importantly, displaying a currency and settling in that currency are separate decisions. A customer can, for example, see and pay in euros, while the merchant receives funds in another currency. Therefore, the customer experience can be localised without the entire underlying payment architecture becoming local too. 

When expanding, keep the payments infrastructure as general as possible

Once customer-facing requirements are clear, the next aspect is determining how much of the underlying setup needs to change. Checkout localisation does not mean building separate country-specific payment infrastructure. Usually, the same integration, data model, reporting, and operational controls can support several market configurations simultaneously. 

At this stage, choosing between a single-PSP and multi-PSP strategy is important. A single-PSP strategy uses one main provider across markets, with a common integration, consolidated reporting, fewer commercial relationships, and simpler reconciliation. These benefits grow more valuable as transaction volumes rise. A multi-PSP strategy uses additional providers when one provider lacks local coverage, competitive economics, or performance, or if redundancy or specialist regional capability is needed. 

Deciding which strategy to use isn’t about whether a model is inherently better, but where and if an additional provider creates enough value to justify the added complexity. A merchant could initially work with one global PSP and add a second in a market where the existing setup lacks an important local payment method (LPM) or acceptable acquiring performance. This way, the merchant can solve a local problem without rebuilding the whole architecture. 

Distinguishing local payment capability from local payment infrastructure is highly relevant, as a merchant may need an LPM without a fully separate local payment stack. Similarly, it may need local acquiring in one market, but continue managing integrations, reporting, and risk controls centrally. 

This common layer matters especially when a merchant’s payment strategy involves multiple providers and markets. Transaction data, fees, refunds, chargebacks, and settlement information should be understood consistently regardless of which PSP processes the payment. Standardisation does not mean every market operates identically. It’s a strategy that provides enough common structure for a deliberately varied setup to stay manageable. 

Localise payment processing when it improves performance and economics

Offering the right payment method does not guarantee a transaction succeeds. Payment processing needs to fit the market. Here, localisation directly affects both payment performance and processing cost, and acquiring is a key decision. 

An acquirer is a financial institution or payment company that processes card transactions and connects the merchant to card networks and issuing banks. For cross-border acquiring, transactions from a country are processed through an acquiring setup in a different location. For local acquiring, transactions depend on a local acquiring relationship. Whichever you choose impacts both authorisation and cost: local acquiring can improve authorisation rates and, depending on the market and transaction type, reduce certain cross-border fees. Because of this, the approval or authorisation rate (the share of payment attempts successfully authorised) is a key measure. 

A payment decline can stem from issuer behaviour, authentication requirements, fraud controls, routing, technical configuration, or insufficient funds. Performance can therefore vary by country, payment method, issuer, and PSP configuration, even when the checkout experience looks identical to customers. 

Routing enables merchants to address those differences. Payment routing determines where a transaction is sent for processing by looking at geography, payment method, cost, risk, and historical performance data. Based on this information, it directs transactions from a specific market to a local acquirer, while others stay with the global provider. Maximising approval rates is not the sole objective. The value of a truly successful transaction should be measured against processing costs, cross-border fees, fraud exposure, and the operational cost of an additional provider or settlement arrangement. 

Authentication is another important optimisation aspect. 3-D Secure (3DS) is an authentication framework for card payments that adds a verification step or data exchange. It can be applied fully or selectively, depending on the transaction, market, and regulations. Unnecessary authentication steps add friction and pose cart abandonment risks, while lax steps raise fraud exposure and liability. Network tokenisation (replacing card details with a token for future use) and intelligent retries (deciding whether and when to re-attempt a failed payment) support the same goal: a merchant can offer the right payment method and still lose transactions if the processing is complex or costly. 

Decide where the money should move

A successful authorisation is only one step of the payment flow. Once approved, the merchant still needs to determine how and where the resulting funds move, which is why settlement and foreign exchange (FX) are central to the economics and control of an international payment setup. 

Settlement means transferring funds from processed transactions to the merchant or another beneficiary according to the agreed schedule and currency. It differs from authorisation in that authorisation confirms a payment can finalise, whereas settlement moves the funds. The two do not necessarily happen in the same currency: a customer could pay in GBP, the PSP settle in EUR, and the merchant could need the funds in an entirely different currency. Each conversion introduces cost, timing, and exchange-rate exposure. 

The merchant needs to map where currency changes occur:

• the customer's payment currency, 
• the processing and settlement currencies, 
• where conversion happens, 
• whether the original currency can be held, 
• which accounts receive the funds, 
• and whether another conversion is needed before the money is used. 

For larger international businesses, multi-currency bank accounts can separate when funds are received from when the business chooses to convert them, giving more control over timing. This process is still governed centrally through an FX and treasury policy, even as individual markets require different settlement currencies. 

The same principle applies, more acutely, to marketplaces and platforms. A customer pays in one currency while the seller expects another. The platform manages the incoming payment, as well as its fees, refunds, reserves, and the eventual payout (the transfer of funds from platform to seller). Mapping the full journey, from customer payment to seller payout, shows where FX is necessary, as converting funds multiple times before paying the seller adds otherwise avoidable cost. While local payout currencies, accounts, and rails may vary by market, orchestration stays centralised. 

Make payments fit your wider business needs

Payment architecture cannot be designed independently of your business. The region where payments are processed and settled affects legal entities, tax, accounting, bank accounts, and reconciliation. For this reason, a setup efficient from a payments perspective alone can create complexity elsewhere. 

You should first consider the legal entity that is receiving and processing the transaction. Depending on its business model and market, a merchant may need a local entity, regulatory compliance, and a commercial strategy. This then shapes acquiring and settlement arrangements, the entity appearing on customer documents, the receiving bank accounts, and how revenue is recorded. Therefore, payment architecture must align with legal and tax planning, not be an afterthought once these decisions are made. 

This also applies to tax and accounting data. A transaction carries information about the merchant entity, customer location, currency, tax treatment, payment method, fees, refunds, and settlement, and that data needs to reach finance and tax processes in a form they can use consistently. For example, the EU’s Central Electronic System of Payment Information (CESOP) rules require PSPs to monitor certain cross-border payments and report on payees receiving more than 25 cross-border payments per quarter. This is only one example of how transaction data can serve regulatory and tax reporting, not just payment operations. 

As markets, PSPs, currencies, and settlement accounts multiply, payment reconciliation (matching what the merchant's systems record as sold and paid against what the PSP or acquirer records as processed and what reaches the bank account) keeps the structure intact. Without a consistent approach, every additional provider or currency becomes another manual process. A standardised data model and central reporting layer lets merchants keep local differences, while retaining a single view of each transaction’s lifecycle. This is one of the clearest places where standardisation brings value. 

Build a global payments architecture with local flexibility

Localisation is usually the most relevant for customer-facing elements. Payment methods, how they and the currency are presented, and checkout language should all reflect how customers in a specific market expect to shop. Payment processing may also require local configuration where acquiring, routing, or authentication directly impact performance, cost, and regulatory compliance. 

Other parts of the payments architecture can usually remain generic: the core payment integration, transaction data model, reporting, reconciliation, risk controls, FX policy, and governance usually provide a consistent foundation under different market configurations. 

 

Payment decision	What may need to be local	What can often be standardised
Payment methods	Market-specific preferences	Integration and reporting
Currency	Customer-facing currency and pricing	FX policy and treasury controls
PSP	Local provider where coverage requires it	Core payment integration
Acquiring	Local acquiring where performance or economics justify it	Central monitoring and optimisation
Checkout	Language, terminology and payment presentation	Core UX principles
Settlement	Local currency or account requirements	Settlement monitoring
FX	Market-specific currency requirements	Conversion policy and controls
Tax and accounting	Local requirements	Group-level data and governance
Seller payouts	Local payout currencies and rails	Central payout orchestration

 

This way, localisation becomes deliberate rather than cumulative, as the merchant does not add a provider, account, currency, or process simply because it exists locally. Each addition has a reason, and the common payments architecture stops local decisions from needing a different operating model in every country. 

A practical payments framework for entering a new market

Before launching in a new country, a set of questions connects the customer experience to the underlying financial and operational setup: 

1. How do customers expect to pay? Identify the payment methods that matter in the market; don’t aim for every option available.
2. What should the customer see? Determine currency, pricing model, checkout language, terminology, and payment method presentation.
3. How should the transaction be processed? Assess PSP coverage, local acquiring, routing, authentication, tokenisation, expected approval rates, and the resulting processing economics, including cross-border fees.
4. Where should the money move? Map processing and settlement currencies, FX conversion points, bank accounts and, where relevant, seller payouts.
5. What needs to be local? Identify requirements relating to entities, regulation, tax, accounting, payment methods, and settlement.
6. What should remain global? Define what stays centrally managed: integrations, data, reporting, reconciliation, risk controls, FX policy, and payment governance.
7. How will the payments setup perform after launch? Monitor approval rates, conversion, payment method usage, processing costs, cross-border fees, FX, refunds, chargebacks, and reconciliation. 

Treat the payment strategy as something that evolves with transaction data, not a one-time launch decision. 

Aim for a connected payments architecture instead of a country-specific checklist

Expanding internationally is not only a matter of accepting payments from more countries. Each new market brings different customer expectations, currencies, payment methods, and operational requirements, so the payment strategy needs to reflect how the wider international business is structured. These decisions are interconnected. 

A payment method choice affects the PSP strategy. Local acquiring affects both payment performance and processing cost, and in turn, entity and settlement requirements. A settlement currency choice affects FX and treasury, whereas adding a PSP improves local coverage but also increases reporting and reconciliation-related work. 

A global payments strategy is therefore a connected architecture, with the merchant deciding where localisation creates commercial value and standardisation operational value, not a collection of individual country decisions. Ultimately, the strongest payments setup accommodates both aspects: the payment experience feels local to the customer, and it is built on infrastructure that stays manageable as the business grows. 

This article is part of The Paypers’ Explainers section. To access other educational materials from this section, click here. If you have suggestions about other topics that could be included in this section, we invite you to write to us at editor@thepaypers.com. 

About the author

Milko Filipov is Managing Director at reMonetary and specialises in payment architecture, PSP selection, and navigating complex payment setups. His expertise covers marketplaces, platforms, billing and subscription models, regional compliance, and global payment expansion. reMonetary helps enterprises of all sizes structure their payment requirements, evaluate the right solutions, and design payment architectures that support their current needs and long-term growth.