Embedded Finance, Interoperability and AI: Three Shifts in Payments
Finance disappearing into other products, rails that finally talk to each other, and models doing the routing. Only one of them changes what a merchant does next week.
Three things are changing in payments at once, and they get discussed as though they are the same trend. They are not, and only one of them changes what a merchant does next week.
Embedded finance payments: the one that changes conversion
Embedded finance means the financial service happens inside a product that is not a bank. A marketplace pays its sellers without anyone opening a banking app. A booking platform takes a deposit in the flow the guest is already in.
The reason this matters is not elegance. It is that every step you add to a payment is a step somebody abandons. Moving the payment into the flow rather than out of it moves conversion, and that effect is usually larger than the fee difference people spend more time arguing about.
For a business, the practical version is an API rather than a hosted page: your system creates the payment, shows it in your own checkout, and listens for a signed callback.
Interoperability: the one that decides whether a rail is a rail
Value that cannot leave a system is stranded. A payment network that only reaches its own users is a closed loop, however good it is inside.
Public blockchains are interoperable in one specific and useful sense: anyone can receive from anyone, without a relationship existing first. That is the property correspondent banking lacks, and it is the reason a corridor can stay open after a bank has left it.
The real interoperability question for a merchant is smaller and more practical. Can your customer pay on the chain they already use, or do you make them bridge? Every bridge is cost, delay, and the most common way funds get lost.
AI: the one being oversold, doing quiet useful work
Models are not making payments. What they are doing is duller and more valuable.
- Routing. Choosing the cheapest viable path for a transfer, and batching what can be batched.
- Risk scoring. Judging a deposit before it is credited, alongside blockchain analytics rather than instead of them.
- Reconciliation. Matching records that nearly agree, which is where finance teams lose their week.
- Integration. Writing the client code from a documentation URL, which has genuinely collapsed integration time.
None of that is a payments revolution. All of it removes work.
What to actually do about it
Put the payment inside your own flow rather than beside it. Accept on the chain your customer already uses. And treat AI claims in payments the way you treat any other claim: ask what it removed from your week.
Frequently Asked Questions
What is embedded finance in payments?
Financial services delivered inside a non-financial product, so the payment happens where the customer already is rather than on a separate page. A marketplace paying its sellers, or a booking platform taking a deposit, without the user ever visiting a bank.
Why does payment interoperability matter?
Because value that cannot move between systems is stranded. Interoperability is what lets a payment made on one network settle to a party on another, and it is the difference between a rail and an island.
How is AI being used in payments?
Mostly in unglamorous places that matter: routing a transfer down the cheapest available path, scoring risk on a deposit before it is credited, and reconciling records that do not quite match. Not in making the payment itself.
Which of these three matters most to a merchant?
Embedded finance, because it changes conversion. A payment that happens inside the flow the customer is already in converts better than one that sends them somewhere else, and that effect is larger than any fee saving.
