Guest blog: The cross-border payment method problem everyone sells as solved

As the payments landscape continues to evolve, it's valuable to hear from people who've built and operated payment systems at global scale. In this guest article, Matthew Leavenworth and Srinivas Rao draw on decades of experience to explore the operational realities of cross border payments and why supporting local payment methods is only part of the challenge.

The views and opinions expressed in this article are those of the authors.

About the Authors:

Srinivas Rao is SVP, Channel Solutions at Boku. Previously, he led digital and emerging payments across Amazon's businesses in the Middle East, India, Latin America, Southeast Asia and Africa, and served on the Financial Stability Board G20 Task Force on Cross Border Payments.

Matthew Leavenworth is a product and partnerships executive with more than 25 years of experience across payments, fintech and AI, including leadership roles at Amazon, Bank of America, Intuit, albo and ModoPayments.

The pitch isn't wrong. The reality is also true.

A merchant decides to launch in Indonesia. The pitch deck from their PSP - pick any of the big four - says one API, two hundred-plus countries, all major payment methods, go.

Six months in, here's what's actually on their hands. Integrations with GoPay, OVO, DANA, and ShopeePay. Bank-transfer rails through BCA, Mandiri, BNI, and BRI, each with a different reconciliation file format and a different cutoff time. Convenience-store cash pickup through Indomaret and Alfamart, where the consumer pays a counter clerk and the merchant gets credited a day or two later, sometimes longer. Each method has different settlement timing. Different refund mechanics - some let you reverse, some require a fresh outbound. Different failure modes - a wallet that says "success" but never settles isn't the same kind of broken as a bank rail that times out.

The pitch was true. The reality is also true. The gap between them is where this piece lives.

And before anyone in the comments says "this is just an Indonesia thing" - it isn't. Run the same exercise in India and you get net banking through more than thirty banks, UPI as both a rail and an interface, cards with EMI options that vary by issuer, and cash on delivery treated as a payment method because functionally it is one. Brazil: PIX and Boleto sitting alongside cards in installments. South Africa: cards plus EFT plus increasingly mobile money. The UAE: cards plus Mada-equivalent local cards plus instant transfers plus cash on delivery, which is still surprisingly large. The list of methods isn't the story. The structural pattern is. Every emerging market, and increasingly every market, looks like this when you actually ship product instead of selling it.

The reframe we want to push: the pitch describes a destination. The reality is a continuous operating discipline. Different verbs.

Payment methods aren't features. They're dependencies.

Most infrastructure companies treat local payment methods as a checklist. We support X, Y, Z. Our coverage map keeps growing. The numbers in the corner of the homepage keep going up.

Each method, in reality, is a living dependency. Like a third-party API your product depends on, except more brittle, less observable, and with regulatory drift baked in. You can't ship a payment method and own it. Every method has its own uptime characteristics. Its own fee structure that changes, sometimes with notice and sometimes not. Its own consumer behavior shifts - the 3wallet that was the default in 2022 isn't necessarily the one consumers reach for in 2025. Adding a method is integration work that ends at go-live. Keeping a method is operational relationship work that doesn't.

Two examples of what we mean. Matt spent 2017–2018 at ModoPayments, a Series A payment-interoperability platform funded by Bank of America and Deutsche Bank, where the central problem was getting different payment systems to talk to each other reliably across versions, regions, and partner constraints. The lesson Modo kept teaching: the continuous reconciliation, the fee-table drift, the partner-side change windows you didn't know about until your monitoring caught the divergence - that's the work, and it never finishes.

Srinivas ran payments for Prime, Prime Video, Kindle, and other digital businesses across the Middle East, India, Brazil, and Mexico during his Amazon tenure. A material portion of those subscribers paid through telco carrier-billing rails. The rhythm of operating with telcos is nothing like the rhythm of operating with banks or card networks. Banks have compliance cycles. Card networks have certification windows. Both are predictable, even if they're slow. Telcos run on quarterly carrier objectives that have very little to do with payments. Their billing systems get reorganized for reasons that are entirely about voice and data, not about your subscription. Their fraud thresholds shift based on regulatory pressure on SMS premium services. You're a small line item inside a large telecom P&L, and you find out about changes the way a small line item finds out about anything - late.

The point isn't that telcos are bad partners. The point is that "we support carrier billing" describes none of this.

And it's not just telcos versus banks. Even within "wallets", the operating realities diverge. GoPay and OVO behave differently - different reconciliation cycles, different dispute mechanics, different APIs that drift on different cadences. M-Pesa is its own world. UPI is a rail with multiple PSP layers behind it; the rail is stable, the PSP layer is not. Treating "wallets" as a category that can be ticked off in a coverage table loses all of this.

The reframe earns its keep when you stop asking "do we support method X?" and start asking "what does our operating relationship with method X cost us, and is it priced into our margin?" Most infrastructure companies can't answer the second question for half their portfolio.

Orchestration is where margin and reliability actually live.

Once you accept that methods are dependencies, the next move is obvious. Orchestration isn't a routing layer. It's the operating system on top of the dependency graph.

The naive view: route to the right method per transaction, done. The real picture is more crowded. Intelligent fallback when a wallet is degraded - and "degraded" is rarely a clean signal. Currency-conversion timing - when do you lock the rate, what's the slippage cost of locking too early or too late, who eats it. (Srinivas is co-inventor on US Patent 7,747,475 for intelligent and firm currency conversion at Amazon, which was the prior-art version of this exact problem from 2008–2010.) Reconciliation across methods that settle on completely different cycles: instant for some rails, T+1 for cards, T+3 for international correspondent banking, sometimes weekly for certain carrier rails. Refund pathways that often don't mirror the payment pathway - your consumer paid via wallet, your refund has to go to a bank account, because the wallet rail doesn't accept inbound credits from your category. Dispute mechanics that vary by method, not just by country.

Each one of those is a design decision. Each one is also an ongoing operational obligation.

There's a second axis we want to put a flag on, because most companies underprepare for it: bank-rail orchestration and consumer-rail orchestration fail in completely different ways, and most companies build for one and inherit the other.

Correspondent banking moves money on T+1, T+2, sometimes T+5 cycles, with cutoffs and currency-conversion windows and intermediary banks taking small bites. Matt spent seven years at Bank of America's Global Transaction Services unit, leading strategy and innovation for what was then a $7B business covering treasury management, trade finance, commercial payments, and merchant services. Failure modes there are slow, visible, and chase-able. A wire that didn't land in 24 hours has a paper trail you can walk. The investigation runs over phone calls and SWIFT messages, and the resolution looks like an explanation.

Domestic real-time consumer rails fail in a completely different shape. SPEI in Mexico, where Matt ran albo's payments stack as CPO from 2021 to 2023. UPI in India, which was reshaping the market during Srini's Bengaluru tenure as Amazon GM of Payments. PIX in Brazil. FedNow and RTP in the US. These rails fail fast and often invisibly. An API that returns success but never settles. A rail that's "up" on the operator's status page but currently degraded for users in one corridor - and you don't find out until the support tickets pile up. Treasury operations and customer-support operations look completely different when you're orchestrating consumer wallets versus bank rails. When you're orchestrating across both, which you do, the moment you go cross-border, the org needs muscles for both, and most don't have it.

The expensive failure isn't a method going down. It's an orchestrator routing around a degraded method that hasn't admitted it's degraded.

Why infrastructure companies underestimate this - the org chart problem.

Here's the harder claim, and where we want to land the analytical move.

The orchestration challenge gets underestimated because it falls between teams. Product owns "what we support". Engineering owns "does the integration work”. Operations owns "did this specific transaction settle”. Finance owns "what does the unit economics look like across methods".

Nobody owns the integrative question: is our portfolio of methods coherent, is our routing logic actually optimal as conditions change, are we picking up the operating-cost drift across the dependency graph?

It's a strategic gap, not an execution gap. Throwing more engineers at it doesn't fix it, because more engineers means more individual integrations shipped - not better portfolio coherence.

The same pattern shows up at the policy level. Srinivas served on the Financial Stability Board G20 Task Force on Cross-Border Payments, which spent considerable time mapping why cross-border corridors are slow and expensive. The conclusion was structurally similar to what we're describing here. Cross-border payments aren't slow because anyone designed them to be, they're slow because the discipline of treating the corridor as a system isn't owned by anyone. Not the originating bank. Not the correspondent. Not the destination institution. Not the regulator. Each party owns their step. Nobody owns the whole.

Same pattern as the Local Payment Method portfolio inside an infrastructure company. Same fix: someone has to own the system view, and they have to be senior enough that the underlying teams take their judgment seriously. Another way to solve this is by creating a P&L view at the infrastructure company. The P&L owner will then look at the margin, costs, operating issues and ensure that it continues to scale and not degrade.

What does that look like in practice? In the companies we've seen do this well, it's not a new team. It's a charter, held by a senior product or operations leader, that gives someone explicit accountability for the coherence of the method portfolio and the optimality of the routing logic over time. They run a scorecard. They run a review cadence. They have authority to deprecate methods, not just add them. Crucially, they have the budget to invest in maintenance work that doesn't ship in a press release.

In the companies we've seen do it badly (and there are more of those) it's nobody's job. So it stays nobody's job until something breaks badly enough to force an org change.

One more piece. The role works only if the company has decided that operating discipline across methods is a competitive moat, not a cost center. In companies where it's framed as a cost center, the role gets cut in the next budget cycle. In companies where it's framed as a moat, it gets resourced and protected. That framing decision is upstream of the org chart. It's a strategic choice the CEO and CFO make, even if they don't realize they're making it.

What this should change

If you're an operator at an infrastructure company, the question isn't "do we support enough methods?" It's "who owns the coherence of our method portfolio, and is the operating cadence around that role anywhere near where it needs to be?" If the answer is fuzzy, that's the work.

If you're a merchant evaluating a PSP, the question isn't "do they support [list of methods]?" It's "how do they handle the methods they support when those methods change, fail, or shift in consumer behavior?" Ask for incident timelines and post-incident reviews on three specific method-level outages in the last twelve months. The answer tells you everything.

If you're an investor, the question isn't "what's the TAM expansion from new methods?" It's "what's the operating-discipline gap between the companies that treat methods as features and the ones that treat them as dependencies?" That gap is where margin and retention diverge.

The broader pattern we want to come back to in a future piece: this same dynamic shows up at the partnership-and-product seam. When orchestration is owned strategically, it pulls partnership and product toward each other. When it's owned tactically, it pushes them apart. That's the next piece.

We're drafting this from the operator seat, both of us still building. Where does this match what you're seeing in your stack? Where does it not? The point of writing in the open is to find out where the model breaks.