Someone in Mexico City finds a product they want. They add it to their cart, they hit checkout, and they expect to pay in pesos because that is how every other transaction in their life works. Instead, the total comes up in US dollars, and none of the card options on screen are ones people around them actually use.
Nothing has crashed. No error has been thrown. The page has loaded exactly as designed. But the purchase is over, and no one on the product team will ever hear about it.
This is episode one of Field Notes, a series where we take a closer look at the small details that decide whether software actually works for the people using it. Not whether it works in staging whether it works for a real person, on their real device, in their real market, trying to do the one thing they came to do. Today: payment methods.
Field Notes, Episode 1: Payment methods — 1 min 43 sec. Full transcript at the bottom of this page.
We see this pattern regularly in projects where a payment gateway is built into the software, and it is far more common than most teams expect.
It isn't limited to Mexico either. It turns up across a number of the markets we test in: a payment gateway that performs beautifully in the region it was designed around, then lands somewhere else without the local payment methods people there depend on. GrabPay in Singapore. KakaoPay in Korea. The specifics change from market to market; the shape of the problem doesn't.
The gateway isn't broken. It was simply built around one set of assumptions about how people pay, and those assumptions don't travel.
When someone can't pay the way they normally pay, they don't file a support ticket. They don't email your product team. They don't leave a review explaining that your checkout doesn't support their preferred wallet.
They go somewhere that does.
From a product standpoint, you see the consequences in the aggregate rather than the individual: cart abandonment creeping up, checkout completion drifting down. And the reason this is so easy to miss is that from the inside, everything still looks fine. Your monitoring is green. Your test suite passes. Your gateway reports healthy uptime. The failure isn't in the system it's in the gap between the system and the market.
That's what makes it expensive. Most defects announce themselves. This one just quietly reduces your conversion rate and lets you assume that's simply what demand looks like in that country.
It's tempting to file this under localisation and hand it to whoever owns the roadmap for international expansion. But localisation reviews tend to catch the visible things currency symbols, language strings, date formats because those are the things you can spot in a screenshot from a desk anywhere in the world.
Knowing that a checkout is missing the two wallets that dominate local commerce requires something different. It requires someone who lives in that market, who pays for things that way every day, and who can attempt a real transaction on a real device on a real local network and then tell you what was missing.
That's the work we do. Global App Testing runs software through a network of testers across the markets our customers operate in, on the devices, payment methods and network conditions those markets actually use, so the problems that only exist in-country stop being invisible to teams who aren't there. Not a simulated environment approximating a market, but the market itself. You can see how that works on our people-powered testing platform, or read more on our approach to payment testing.
If you have software with a checkout function, it's worth taking a step back and asking a fairly simple question: are we embedding enough local payment options for every market we're operating in?
Not "does our gateway support these markets" gateways usually claim broad coverage. The question is whether the options a customer in São Paulo, Seoul or Singapore sees on screen include the ones they would reach for by instinct.
In our experience, that gap is often the difference between someone completing a purchase and someone quietly disappearing without ever telling you why.
Veronica, Marketing Manager at Global App Testing:
Hi everyone! I'm Veronica, Marketing Manager at Global App Testing. Welcome to Field Notes, where we take a closer look at the details that shape whether software actually works for the people using it.
Today, I'm going to go through something that we've seen in a number of projects we encounter where there's a payment gateway built into the software. It's a pattern that's a lot more common than people expect.
An example of how this looks in practice is when someone in Mexico City goes to pay for something, and they're expecting to check out in pesos like normal, but instead the software charges them in US dollars and on top of that, none of the card options on screen are ones that people there actually use.
And we don't just see this in Mexico. It shows up in a number of markets we test in, where a payment gateway works really well in one region but just wasn't built around the local payment methods people actually use somewhere else, whether that's GrabPay in Singapore or KakaoPay in Korea.
So what tends to happen next is pretty predictable, because when someone can't pay the way they normally would, the easiest thing for them to do is to look somewhere else that does support the local payment method.
From a product standpoint, you end up seeing cart abandonment creep up and checkout completion drop, and a lot of the time companies don't even realise it's happening, because from their side everything still looks like it's working fine.
So if you've got software with a checkout function, it's probably worth taking a step back and asking whether you're actually embedding enough local payment options for the markets you're in, because in our experience that gap is often the difference between someone completing a purchase and someone quietly disappearing without ever telling you why.
A checkout that doesn't accept local payment methods isn't a bug in the usual sense. It passes every test you've written, satisfies every uptime check, and reports back that everything is fine. The only people who know it's broken are the customers who left.
Finding it means testing where your customers are, with the payment methods they use. Talk to us about putting your checkout in front of testers in your target markets, and find out what your payment flow looks like from the other side of the world.
Field Notes is a series from Global App Testing on the details that determine whether software works in the real world. Next episode coming soon.