Insights · 5 min read
Selling across borders is rarely about the API call. It is local payment methods, currency, refunds, and reconciliation. Here is what a real setup involves.
By GGP Editorial
When you sell across borders, the hard part of taking payments is rarely the API call. It is everything around it: local payment methods, currency conversion, refunds, and reconciliation. A gateway that works well in the United States can leave Brazilian or Singaporean customers with no way to pay the way they are used to.
Customers pay with what they already trust. In Brazil that is Pix and boleto, in much of Asia it is digital wallets, in Europe it is often bank transfers alongside cards. If your checkout only shows a card form, you quietly turn away a large slice of each market.
A good cross-border setup offers at least the top local method for each market you care about. That usually means working with a gateway or a second provider that aggregates local rails, so you do not have to sign ten separate contracts and maintain ten integrations.
| Market | Common local methods |
|---|---|
| Brazil | Pix, boleto, local cards |
| Singapore | PayNow, cards, e-wallets |
| United States | Cards, Apple Pay, ACH |
| South Africa | Cards, EFT, instant EFT |
Currency is the second thing that trips teams up. You can present prices in the customer's currency or bill in your own. Presenting in theirs usually converts better, but it pushes the FX risk onto you or your provider. Decide early whether you absorb the conversion or pass it through, and make sure your gateway's FX markup is visible, because it can quietly eat 2 to 4 percent.
Also decide where tax and fees land. A sale through a gateway is not the amount you receive. Refunds, chargebacks, and currency swings all reduce the net. Your finance team needs a report that shows gross, fees, and net per transaction per market. Without it, cross-border revenue looks bigger than it is.
Integration work itself is usually days, not weeks, for a standard checkout. What takes longer is everything the happy path ignores.
Plan for the integration to be quick and the surrounding work to take the rest of the sprint. Teams that budget only for the happy path run out of time right at launch.
The cleanest way to handle all this is to keep your own order and payment abstraction. Your system stores the order, calls the gateway or a few of them, and records the result. That way you can add a new local method or swap a provider without rewriting your checkout. This is a standard pattern, and it is what we build for clients who sell in more than one market.
It also keeps a clean record of every attempt, which makes refunds and disputes far easier to handle later. The moment you have two gateways and three currencies, a messy data model becomes a real liability.
Three things usually surprise teams on their first cross-border launch.
The first is refund timing. A refund that settles instantly in the US can take five business days through a local rail in another country. Customers do not care whose fault the delay is. You need a clear message and a policy that survives slow rails.
The second is chargeback handling. Each market has its own dispute rules, and some local methods barely support chargebacks at all. If you sell in a market where a specific method has a high fraud rate, turn it off for first-time customers or low-trust orders until you have the data to keep it.
The third is the quiet cost of currency. A customer pays in one currency, the gateway converts, and you settle in another. The spread between those rates, plus the gateway's fee, can surprise you on the P&L if no one is watching it monthly.
None of this is a reason to avoid selling cross-border. It is a reason to treat payment as a product decision, not a technical checkbox, from the start.
We are a software development company founded in 2018, with 40+ engineers and 300+ delivered projects. We have built payment integrations and financial systems for clients in Brazil, South Africa, Singapore, and the US, so we have seen how different each market's rails actually are. We run overlapping hours, keep a dedicated group per project, and work in English and Portuguese.
Tell us what you are building and where you are today. We typically reply within 24 hours.
