Start with how customers already pay, not with a channel list
The most common mistake is starting from a provider's list of supported methods and ticking boxes. Start instead from what a customer in that country did the last time they paid for something online, and work backwards. Three sources will get you most of the way there: the central bank or national payments body, which usually publishes scheme descriptions and statistics; your own analytics, if you already have traffic from the country, including checkout abandonment by country and device; and a handful of competitor checkouts, which you can simply look at. Combine usage with context. A method can be enormous by volume and still wrong for you if it is mostly used for person-to-person transfers, or if it does not work well on the web, or if your average order value sits outside its normal range. The output of this step should be a short ranked list, not a wish list: three to five candidate methods, each with a reason it might matter to your specific customers.
- Read the central bank or national switch page for each candidate method before reading any provider marketing.
- Check whether the method is genuinely usable in an online checkout rather than only in person or in an app.
- Look at three competitor checkouts in the country and note which methods sit at the top of the list.
- Match the method to your average order value, because some rails are built for small tickets and others are not.
Check what you can actually be onboarded for
Coverage and eligibility are different things, and confusing them wastes weeks. A provider may display a method on its website and still be unable to board you for it, because eligibility depends on where your company is registered, what you sell, how you sell it and who will settle to you. Build a small matrix, one row per method, with four columns: can a foreign entity use this; which legal entity contracts with me; which entity settles to me; and what documents are needed to open it. Do this before you integrate anything. Also check the industry question early. Categories such as digital content, gaming, travel, supplements, ticketing and anything resembling financial services can require specific approval, and a rejection at the end of a build is far more expensive than a rejection at the start. Where a conclusion sounds absolute, ask for the rule in writing and check it against the regulator's own publications rather than a blog summary.
- Ask each provider to confirm in writing that your registration country and category can be boarded for each method.
- Record the contracting entity, the settling entity and the currency path separately, because they are often not the same company.
- Clear your product category with the risk team before your engineers start any integration work.
- Treat any claim about what is mandatory as unverified until you see it in an official rule or a written confirmation.
Map settlement, currency and FX before you set prices
Settlement is where a good-looking pricing quote quietly becomes a worse one. Work out the full path of a single order: the currency the customer pays in, the currency the provider books it in, when conversion happens, whether you can hold the local currency, and which account the money finally lands in. If your customers pay in real, you advertise in dollars and your suppliers invoice in dollars, you may be converting twice, and the cost sits in the exchange rate rather than in a line item you can compare. Ask for the reference rate the provider uses and how the margin is applied, then test it against a public rate on the same day. Also settle the timing question: how many days from capture to available balance, whether the count uses business days, and whether a payout threshold means small balances sit for longer. Then, and only then, set your prices.
- Draw the full currency path for one order, from the customer's payment to your bank statement.
- Ask which reference rate is used, when the rate is fixed, and whether you can hold the local currency instead of converting.
- Confirm whether payout days are calendar or business days, and check the country's public holiday calendar.
- Check for a minimum payout threshold, because it quietly delays small balances on a new account.
Launch one method at a time
It is tempting to switch on everything the provider offers and let customers sort it out. Resist that. Each method brings its own failure modes, its own refund behaviour and its own line in your reconciliation, and launching six at once means you cannot tell which one is causing the problem you are about to spend a week diagnosing. Start with the single method your research says matters most, plus cards if your customer base expects them. Run it for two to four weeks, or until you have enough orders for the numbers to mean something. Then add the second, giving it a real place on the checkout rather than hiding it behind a more link. Each addition should be justified by a signal you can name: a share of customers who abandon at the payment step, support tickets asking for a specific method, or a segment of your traffic you are clearly failing to serve.
- Launch the top-ranked local method first, alongside cards if your customers expect them.
- Give each new method a visible position on the checkout rather than burying it in a dropdown.
- Set a review point with a volume threshold before you add the next method.
- Keep a rollback path, so a method that misbehaves can be switched off in minutes rather than after a release.
Instrument the checkout so the next decision is data-led
Most merchants can tell you their conversion rate. Far fewer can tell you the conversion rate per payment method, and without that number every future decision is guesswork. At minimum, capture for each method: how often it is selected, the share of attempts that succeed, the median time from attempt to confirmation, the share of orders that later refund, and the reason codes on failures where your provider exposes them. Watch abandonment at the moment of method selection too, because customers who see no method they recognise will simply leave without appearing in any failure report. Pair the quantitative view with a qualitative one: ask ten customers in that market what they expected to see. Financial inclusion data is useful context here, because account ownership and smartphone penetration in a country tell you roughly what share of your addressable customers can use a bank-linked method at all.
- Track selection share, success rate, time to confirmation and refund rate separately for every method.
- Log abandonment at the payment-method selection step, not only after a method is chosen.
- Ask a handful of local customers which method they expected to see, and compare it with your data.
- Review the numbers monthly and remove methods that carry cost without carrying orders.
A short pre-launch checklist
Before you turn the market on, walk this list. The checkout shows local currency and the customer's language. Prices, delivery estimates and the refund policy are visible before payment. Every method you have enabled has been tested end to end in production, including a real refund and a real failed payment, not only a sandbox success. Webhooks are idempotent and you have confirmed you can handle a duplicate notification without shipping twice. Finance has seen a sample settlement report and can reconcile it to your order system. Customer support knows how to issue a refund on each method and how long it takes to reach the customer. And you know who to call when something breaks, in your timezone, with a response-time commitment. None of this is exotic. Almost all of it is the difference between a market that works and a market that quietly leaks orders for months.
- Test success, failure, timeout, cancellation, partial refund and duplicate notification for every enabled method.
- Make sure finance can reconcile a sample settlement report to your order records before launch day.
- Confirm support can issue a refund on each method and can tell a customer how long it will take.
- Agree an escalation path and response-time expectation with the provider before you need it.
Questions merchants ask
How many payment methods should I offer in a new country?
Fewer than you think. Start with the one or two methods your target customers use most, plus cards if they are expected there. Too many options add cognitive load at the checkout and add reconciliation work for you. Add the next method only when your data shows a specific group of customers you are failing to serve.
Can I enter a new country without a local company?
Often yes, through a provider that contracts with foreign entities, but it is not a universal rule. Eligibility depends on the country, the payment method, your industry and the provider's own licence. Confirm in writing which legal entity will contract with you and which will settle to you before you commit to a build.
Should I launch with cards first and add local methods later?
Only if cards genuinely dominate in that market. In several emerging markets cards reach a minority of online shoppers, so launching cards first means launching with a ceiling on your conversion. Start with the method your research says customers use most, then add cards if the data supports it. Whichever you pick, instrument the checkout per method so the decision can be reviewed with real numbers.
How do I know which payment method is losing me sales?
Instrument the checkout per method. Record selection share, success rate, time to confirmation and subsequent refund rate for each one, and log abandonment at the point where customers choose a method. Customers who see no method they recognise leave without generating a failed-payment record, so that step needs its own measurement. Pair that with a handful of customer interviews, because the data shows what happened rather than why.
What is the biggest hidden cost when entering a new market?
Currency conversion. It is often embedded in the exchange rate rather than shown as a fee, so it does not appear when you compare headline percentages. Ask which reference rate is used, when the rate is fixed, whether you can hold the local currency, and whether conversion happens once or more than once on the path to your bank.
How long should I test before adding another payment method?
Long enough to have orders you can trust, which usually means two to four weeks of real traffic or a fixed number of completed orders. If volume is very low, extend the window rather than drawing conclusions from a handful of transactions. Set the threshold before you launch so the decision is not made on optimism.