By Obinna Nna
I have seen the same mistake happen over and over again while building payment products in Africa and Europe for the past three years. A product team makes a payment experience more relevant to a specific area by translating text, changing currency symbols, changing the onboarding process to fit local ID formats, and adding a few payment methods that are only available in that area. They send it off to a new market with confidence, but within weeks of launch, they see failure rates rise, support tickets multiply, and conversion rates drop.
Usually, the post-mortems look at the wrong things. Teams look at the user interface again. They test the onboarding funnel again. They change the order of the fields and rewrite the text. They rarely look into the assumption that quietly underpins every product decision they make: that payment infrastructure is pretty much the same everywhere and that a well-designed surface can cover up any differences that might be there.
Most of the product teams I’ve worked with see localization as a problem with four parts: language, currency, regulatory disclosures, and support for local payment methods. This framing is not wrong, but it is very incomplete. It treats localization as an integration issue—adding the right rails, showing the right options, and translating the right strings—when it is really an architectural issue that affects almost every part of the product, even parts that don’t have a UI at all.
The teams that have the hardest time are often the ones that do well at the visible level. Their checkout looks like it belongs there. Their onboarding process follows local rules. They have the right payment options and the right branding. And yet their transactions fail at rates much higher than in their home market; their reconciliation processes break down within the first month; and their customers’ trust, especially in markets where trust is the hardest thing for a fintech to earn, goes away faster than they can rebuild it.
The reason is that payment systems don’t work the same way in every market, and the differences are significant. They are based on time, structure, and behavior.
Think about what happens between the time a user clicks “Pay” and the time the money is confirmed in the recipient’s account. This process happens almost right away on most modern rails in Nigeria. NIBSS Instant Payment moves money in seconds, and users expect the recipient’s balance to show the transaction right away. People don’t see any delays as a quirk of the system; they see them as proof of failure. If a user doesn’t see confirmation within thirty seconds, they will either try again, dispute, or give up. This is not a choice. It is the learned behavior of a market shaped by mobile-first banking and a payments culture based on real-time rails.
In most of Europe, especially for transactions that go through standard SEPA Credit Transfer instead of SEPA Instant, the same event can take hours or even a whole business day. This process is how the user experience is built. People don’t expect to get confirmation right away. They want a clear timeline for when the settlement will happen, cut-off times that are straightforward to understand, and well-planned ways to communicate status. SEPA Instant is changing things quickly, but the idea that a payment is a process with stages, not just one moment, is still very much a part of how Europeans move money around. A product team that treats these as the same event and creates a single confirmation screen for both has not localized the experience. They have combined two payment experiences that are structurally different into one, and the new product will not meet the needs of users in either market.
The same difference shows up in modes of failure. In several African markets I’ve worked in, transaction failures often look like silence: a user submits, nothing happens, and they have to decide for themselves whether the transfer worked, failed, or is still in progress. The product implies that failure messaging, retry logic, and reconciliation tools are not rare. A significant number of users use them every day as core flows. In the European markets I’ve shipped to, failure modes act differently: declines are usually clear, error codes are the same, and users expect specific reason codes that let them take action. If you don’t first understand the differences between the two markets, you won’t be able to create a single error-handling system that works for both. One group of users will be confused, and the other will be underserved.
Payment infrastructure mapping is the framework I’ve come up with and now use for every cross-market product decision I’m in charge of. It makes a team check four levels of the transaction lifecycle before making any product decisions, not after the product is released, when mistakes are most expensive. The layer of settlement. What time does money really move? Is the rail real-time, almost real-time, or batched? What are the cut-off times, and what happens to a transaction that is submitted at 23:59 and 00:01? This layer controls all of your product’s confirmation screens, notifications, and “pending” states.
The layer of failure. What does it look like when this rail fails? Is it clear or not? Which error codes show up and which ones don’t? What does the underlying system do when it fails, and what should the user do when it does? This layer is in charge of how you handle errors, how you help customers, and a lot of your customer service work. The layer of trust. How can someone in this market be sure that a transaction went through? In some places, the SMS confirmation from the user’s bank is the only thing that matters, and your in-app confirmation is not trusted until that SMS arrives. In some cases, just the confirmation in the app is enough. This layer controls how you send notifications, how you design receipts, and how your product fits in with the institutional channels that users already trust.
The layer for compliance. What regulatory events does this deal set off? What are the limits, reporting requirements, and verification requirements that go along with it? When do these responsibilities become clear to users through extra verification steps, transaction limits, or holds? And how should the product let users know about them? This layer controls your KYC strategy, the way you monitor transactions, and how well you can defend yourself when regulators look into you.
A product team that has mapped these four layers for every market it works in is in a much better position than one that hasn’t. The mapping doesn’t have to be very detailed. From what I have seen, a single shared document that clearly shows how each difference in the layer across markets is enough to account for about 80% of the decisions that would have been made automatically.
The fintech industry is now striving to grow in more than one market. African fintechs are moving into Europe. For the first time, European fintechs are really getting into African markets. Global companies are doing business in both places on a large scale. The best teams in this expansion won’t be the best at surface localization. They will be the ones who understand that localization is more about infrastructure than design.
This is both a warning and an opportunity for product managers. The warning is that surface-level localization is a trap that eats up real time and money before it becomes clear that it doesn’t work. By then, the cost of fixing bad decisions is many times higher than the cost of avoiding them. The opportunity is that any product manager who can do the deeper work, who can map the four layers, surface the structural differences between markets, and design products that respect them, becomes immediately valuable in an industry where this skill is still rare.
Obinna Nna is a Senior Product Manager