Embedded Payments optimize Themselves. The Models Pricing Them Don't.

Close to one in 13 online payments fails, according to Stripe. The card works. The money is there. The customer is trying to buy something. But something between the checkout button and the issuing bank says no, and the transaction dies on a route that, in hindsight, was the wrong one.

That failure rate has turned payment routing into an optimization problem that the platforms are now solving in real time. Over the past few years, companies like Stripe and Adyen have built systems that pick the best processor for each transaction, retry through a different acquirer when the first attempt bounces, settle in whatever currency makes the most sense and swap out static card numbers for dynamic tokens that issuing banks trust more. All of it happens before the customer has time to wonder whether the page is loading.

The part that hasn't kept up is the financial model wrapped around all of this. "When a payment self-optimizes toward a different corridor, the original route simply reverts to being a passive alternative," says Ran Cohen, CEO and cofounder of BridgerPay. "Once the platform picks a different path, the acquirer, local versus cross-border acquiring setup, approval profile, fee stack, FX exposure, retry pattern and even settlement timing may also change." The right question for a finance team, Cohen argues, is no longer what they expected a payment to cost but what path it actually took and what economics that path created.

How the Stack Got Ahead of the Spreadsheet

Worldpay's Global Payments Report, released in March 2025, pegged global digital payment spending at $18.7 trillion in 2024, up from $1.7 trillion a decade earlier, and projected that number to clear $33.5 trillion by 2030. The interesting thing about that growth is where it came from. A big chunk of it traces back to the payment rails themselves getting smarter, processing more successfully and handling cross-border complexity that used to kill transactions.

Intelligent routing is the most visible example. The system evaluates a transaction's card type, issuing country, currency and device signals, then sends it to whichever processor has the best historical approval rate for that combination. If the first attempt fails, it retries through a different acquirer, often before the customer notices anything went wrong. Network tokens, which replace static card numbers with dynamic credentials from the card network, have produced a 4.6% authorization rate lift on Visa's card-not-present transactions globally compared with traditional card numbers, according to Visa's data. Local acquiring (processing a transaction in the cardholder's own country) lifts authorization rates further and sidesteps cross-border interchange surcharges.

Then there's the currency side. FX tooling can now present prices in one currency and settle in another, or hold balances in multiple currencies without converting at all. A single checkout can trigger routing, tokenization, local acquiring and currency localization at the same time, and each of those decisions changes the cost structure of the transaction. The finance team reviewing month-end numbers may be looking at a transaction that took a completely different path than the one their model assumes.

Standout: In its H2 2024 shareholder letter, Adyen reported that its AI-powered optimization tool, Uplift, lifted conversion rates by up to 6% in initial pilots. Its intelligent routing for U.S. debit cut costs by 26% while raising authorization rates.

Where the Gap Shows Up

Finance teams built their models for a world where a payment took one path and stayed there. You knew the processor, the interchange tier, the settlement currency, the timeline. That assumption held for a long time, and for a lot of companies it still drives how they price cross-border volume and set reserve levels.

Cohen has watched this play out across BridgerPay's client base. "Treating cross-border payments as a fixed cost is usually too simplistic in practice," he says. "Real cost moves at the transaction level based on route choice, local acquiring versus international acquiring, interchange and scheme fees, network and external partner fees, FX and retry behavior." The gap, he says, tends to surface as "margin leakage, country- or corridor-level P&L distortion and reconciliation variance between forecasted payment costs and the fees that were actually settled."

Lets take a look at interchange. When a payment routes through a cheaper domestic acquirer instead of the assumed international one, the scheme fees drop. If the pricing model still charges for the expensive path, the business is either overcharging customers or misreading its own margins, and at volume, that variance compounds quickly.

FX creates a similar problem. What the customer pays (the presentment currency) and what the business receives (the settlement currency) can diverge in ways the treasury model didn't anticipate. A customer in Tokyo pays in yen. The platform might settle in dollars, or it might hold yen in a multi-currency balance and skip conversion entirely. Each of those paths carries a different spread and a different hedge requirement, and a treasury model that treats FX as one lump conversion at month-end won't pick up any of it.

Settlement timing is another blind spot, because a reserve model built on a standard T+2 assumption will tie up cash on corridors that settle faster and leave gaps on corridors that settle slower. And on the fraud side, Visa's data shows tokenized transactions produce a 30% reduction in online fraud compared with traditional card numbers. If the risk model hasn't been updated to reflect what the payment stack is already doing, the business is holding reserves against a threat profile that its own technology has already reduced.

The Data Exists. Getting It to Treasury Is the Problem.

"Best-in-class stacks can show the optimization layer in near real time, but treasury often still acts on a delayed version of the truth," Cohen says. "Visibility may exist in the payments layer before it becomes actionable in treasury unless those reporting streams are tightly integrated."

If reporting reflects the intended corridor rather than the executed one, a business can misstate corridor profitability, fee accruals, FX impact and payout timing. Cohen says he's seen cases where financial reporting was materially off because it didn't account for what the platform was doing underneath. Think about a platform processing in 30 countries: the optimization layer routes a Brazilian transaction through a local acquirer, retries a failed Indian payment through a different processor, settles a Japanese transaction in yen instead of converting to dollars. Each decision changes the economics. If the treasury model still assumes a single default route for each country, every one of those optimizations creates a discrepancy between what the company thinks it spent and what it actually spent.

What does a company running embedded payments with a static operating model look like? Cohen describes it: "Hard-coded routes, average-cost assumptions, periodic manual rule changes and limited visibility into why a payment succeeded, failed or got rerouted." The cost, he adds, is lower approval rates, avoidable processing fees, slower response to outages, more manual reconciliation and weaker control over FX and cash flow.

What the Fix Actually Looks Like

The payment stack is already producing the data, but is anyone outside the engineering team looking at it? That’s what we should worry about. Payment costs need to be tracked per corridor, per route, per cohort and per payment method. Treasury and payments teams need shared, live feeds instead of monthly reconciliation. Reserve and hedge models need to reflect what the transaction actually is now: dynamically routed, tokenized and locally acquired. The infrastructure is already there, what remains is proper measurement.

Embedded payments have become software. They should be measured by conversion rates at the corridor level, by margin capture per route, by cost variance between what was forecasted and what was settled. The companies that figure out how to close that measurement gap are going to price their payment stack accurately. Everybody else is going to keep discovering, quarter after quarter, that their payment costs don't match their models, and they'll keep writing it off as a reconciliation problem instead of seeing it for what it is.

The Bottom Line

Embedded payment systems reroute, retry, localize and tokenize transactions on the fly, while the pricing, treasury and risk models around them still assume payments follow a single predictable path. The resulting mismatch leaks money across interchange, FX spreads, settlement timing and fraud reserves. Closing the gap means integrating payment-level data into financial models in real time and measuring costs by corridor instead of by average.