Checkout localisation: currency, language and payment methods by market

A customer in Riyadh, São Paulo or Almaty who reaches your payment page has already decided to buy. What happens next depends on whether the page looks like it was built for them: a price in their currency, text they can read in the direction they read it, the method they pay with every day near the top, and a form that accepts their address and ID. Each mismatch is a small reason to stop, and the reasons add up.

This article sets out what localising a checkout involves, what the evidence says about why it matters, how the details differ in Latin America, Turkey, the Gulf and Central Asia, and the mistakes that undo the work.

What does localising a checkout involve?

Six layers, each of which can be right or wrong independently:

1. Currency. The price shown, and the currency actually charged, in the customer’s own money.
2. Language and script. Copy, error messages and method names in the customer’s language, and a right-to-left layout for Arabic.
3. Method choice and order. The local payment methods people in that market use, with the most common first.
4. Form fields. Address, phone and tax ID fields in the formats local providers accept.
5. Instalments. Card or wallet instalment plans where shoppers expect to split the price.
6. Defaults and overrides. A sensible guess of country, language and currency, which the customer can change.

Most cross-border checkouts get one or two of these right. The rest are usually inherited from the merchant’s home market.

Why does localisation change conversion?

Because most of the reasons people give for abandoning a purchase are things localisation fixes. Baymard Institute puts the average documented cart abandonment rate at 70.22%, based on 50 studies. In its survey of US online shoppers, the reasons given for abandoning, beyond “just browsing”, include:

Reason for abandoning	Share of shoppers
Extra costs too high (shipping, tax, fees)	40%
Did not trust the site with card details	19%
Checkout too long or complicated	17%
Could not see or calculate the total cost up front	12%
Credit card was declined	10%
Not enough payment methods	9%

Those are American shoppers, most of whom pay by card. In markets where the everyday method is a bank transfer, a wallet or a domestic card scheme, a checkout that offers only international cards fails on several rows at once: too few methods, more declines, and a foreign-looking page that is harder to trust.

Language matters as much. CSA Research surveyed 8,709 consumers in 29 countries, including Brazil, Egypt, Turkey and Russia, and reported in July 2020 that 76% of online shoppers prefer to buy products with information in their own language and 40% would never buy from websites in other languages.

How should you handle currency?

Show the price in the customer’s currency from the product page onward, and charge in that currency where your providers can. The two are not the same thing. A store that converts prices for display but charges in US dollars leaves the final amount to the customer’s bank, which applies its own rate and possibly a foreign transaction fee. The customer sees a different number on their statement than on your page, which is exactly the “could not see the total cost” problem from the table above.

Some local methods make the decision for you, because they only work in local currency. Stripe’s documentation, for example, notes that Boleto does not support any currency other than Brazilian reais. Pricing in BRL is a precondition for offering it at all.

Format the currency the local way too: the local decimal separator, the local symbol in its usual position, and the currency code wherever a symbol such as ”$” is shared by several currencies. A customer should never have to wonder which dollar or peso a price is in.

What does the language layer involve beyond translation?

For most languages, translation plus local error messages, method names and support contacts. For Arabic, it also means a layout that runs right to left. The W3C’s guidance on right-to-left text in HTML is the practical reference:

• Set dir="rtl" on the html element. The lang attribute does not set direction on its own.
• Use logical CSS properties, start and end rather than left and right, so the layout flips without a separate stylesheet.
• Use dir="auto" on fields where customers type, since a name or address may start in either script.
• Isolate inserted text such as names and labels with the bdi element so it does not reorder the text around it.

Card numbers, expiry dates, IBANs, phone numbers and email addresses stay left to right inside an Arabic page. Check how each one renders, especially in error messages that mix Arabic text with a number.

There is a provider-side catch. Stripe’s Boleto integration requires the name, address and city fields to contain at least one character from the Basic Latin block. A customer who types their address only in Arabic or Cyrillic script can hit a validation error the checkout never explains. Know which providers need Latin characters, and either ask for a Latin version or route those payments to a provider that does not.

Which methods should appear first, by market?

The method most customers use goes first; a handful of alternatives follow. Here is how that looks in five markets, with links to our country guides:

Market	Lead with	Also offer	Local detail to get right
Brazil	PIX	Cards with instalments, Boleto	CPF or CNPJ for some methods; BRL only for Boleto
Mexico	Cards with meses sin intereses, and SPEI	OXXO Pay	Instalment plans shown after the card number
Turkey	Domestic cards with instalments	Troy cards, wallets	Instalment options per card
Saudi Arabia	mada	Visa and Mastercard, Tabby, stc pay	Arabic, right to left
Kazakhstan	Kaspi	Visa and Mastercard	Instalments inside the Kaspi app

The numbers behind some of these choices are large. In Saudi Arabia, SAMA data reported by Arab News shows online spending with mada cards of SR29.86 billion in July 2025 alone, across 149.74 million transactions, a series that excludes payments on the international card schemes. In Kazakhstan, Kaspi.kz reported total payment value on its Payments platform of KZT 44.2 trillion for 2025, up 19% on the year.

Order is not cosmetic. A customer who scrolls past three methods they do not use before finding theirs has been told, three times, that the page was built for someone else.

Which form fields change by market?

Ask for what the chosen method needs, after the customer has chosen it. The fields that vary most are these:

• Tax ID. Stripe’s Boleto integration requires a CPF of 11 digits for individuals or a CNPJ of 14 digits for businesses, written with or without punctuation. Label the field in Portuguese, accept both formats and check the length before submitting.
• Address. For the same method, Stripe requires a Brazilian postal code in the format XXXXX-XXX and a two-letter state code. Addresses in other markets may not fit a US-style form at all; make postcode and state optional where the market does not rely on them.
• Phone. Wallets and instant payment apps often identify customers by mobile number. Store numbers in international format with the country code, and let customers type them the way they are used to.
• Name. Some markets put the family name first, and some customers have one name. A single full-name field avoids forcing the wrong split.

Every extra field is a reason to stop, so do not collect a CPF from a customer paying by card if your card provider does not need it.

How do instalments fit into a localised checkout?

In some markets the instalment plan is part of the price. Garanti BBVA’s report on card payments in Türkiye, based on BKM data, found that instalments accounted for 57.8% of e-commerce purchases in 2025, up from 55.5% in 2024. A Turkish checkout without instalment options is, for many shoppers, a checkout without the price they planned to pay.

In Mexico, card instalments are called meses sin intereses. Stripe’s documentation describes plans of 3, 6, 9, 12, 18 and 24 months on Mexican consumer credit cards from supported issuers. The merchant receives the full amount minus a fee, and the customer’s bank collects over time. The cost is real: Stripe’s additional fee runs from 5% for a 3-month plan to 22.5% for a 24-month plan, with default minimums from MXN 300. Stripe also recommends showing plans only after the customer enters a supported card number, because eligibility depends on the issuer.

In Kazakhstan, instalments live inside the wallet. Kaspi.kz reported that buy now, pay later loans made up 41% of the KZT 11.7 trillion it originated through its fintech platform in 2025. Offering Kaspi at checkout brings those plans with it.

Worked example: what does localisation recover?

Example figures, for illustration only.

An online electronics store sells into Saudi Arabia with an English, US-dollar, card-only checkout. In a month, 10,000 customers reach the payment step and 5,200 complete it. The team localises in two steps and measures each one against the same traffic.

Step	Change	Completed payments
Starting point	English, USD, international cards only	5,200
Step 1	Arabic right-to-left layout, prices and charges in SAR	5,700
Step 2	mada first, then cards, then an instalment option	6,600

The gain of 1,400 payments a month is the number that matters, and it only counts if it is measured properly: on payment-step completion by country, method and language, over the same period, against a control group. A localisation change that raises completion but also raises declines, for example because a new provider handles mada badly, needs routing work as well as design work.

What are the common mistakes?

• Translating and stopping there. Currency, methods and fields still say “foreign”.
• Converting prices for display but charging in dollars. The statement amount will not match the page.
• Using one method order for every market. The right first method in Brazil is wrong in Kazakhstan.
• Asking for every field up front. Collect a tax ID only for methods that need it.
• Breaking right-to-left with numbers. Card numbers and amounts that reverse inside Arabic text look like an error.
• No override for detection. Travellers and expatriates need to pick their own country and currency.
• Forgetting the refund path. A method customers can pay with but cannot be refunded through needs another way back; our article on why payouts are harder than payments covers it.

How does Omno support a localised checkout?

Omno’s hosted checkout shows each customer the cards, local methods and crypto options they are eligible for in their country, in an order and grouping you configure. The payment session names the currency, the Web SDK lets the customer change language at runtime, and routing and PSP-eligibility rules can send each method and currency to a provider that handles it locally. The checkout guide covers the session fields.