It is tempting to treat payments as a single problem: move value from A to B, then notify both sides. Once a product operates in more than one market, that abstraction starts to leak.
What a user calls “paying” is usually a local rail, a local account system, and a local set of expectations about speed, cost, and failure. PayID is not Zengin. A real-time credit in one country is not a batch settlement in another. The merchant may want one integration. The money still has to travel through something specific.
Abstraction is useful until it hides the rail
A platform should hide unnecessary difference. Merchants should not have to learn every scheme’s message format. They should not have to rebuild onboarding for each market from scratch.
But if the abstraction hides the rail completely, the product loses the ability to explain itself. Settlement times change. Returning funds works differently. The definition of “instant” is not universal. When something fails, the merchant needs to know which local process they are waiting on.
Good infrastructure therefore has two jobs. It presents one way to collect, route and pay out. It also preserves enough of the local rail that operations, risk and support can still reason about what happened.
Local rails change the product
Real-time account-to-account payments are not just a cheaper card alternative. They change when funds become usable, how refunds work, and what kind of reconciliation a business needs.
They also change what “global” can mean. A company can have customers in several countries without having a single global payment method. The global part is the orchestration: one set of accounts, policies and records sitting above rails that remain local.
That is why I am cautious about describing payment infrastructure only in terms of routing. Routing is necessary. It is not sufficient. Treasury, payouts, and the way sub-merchants are settled are part of the same problem, especially for platforms that operate across markets.
Reliability is local before it is global
A multi-market system fails locally first. One rail is down. One bank is slow. One provider’s status codes stop matching reality. The rest of the platform can be healthy.
The design question is whether that local failure stays local. Can the rest of the markets continue? Can the merchant see which corridor is affected? Can payouts continue when collections cannot, or the reverse?
Those are the same questions I care about in research, in a different form: what should a system do when part of its knowledge is reliable and part is not? In payments, the answer cannot be to stop everything, and it cannot be to pretend the uncertain part is fine.
Local rails matter because they are where that uncertainty actually lives.