Why Embedded-Payments Adoption Stalls Inside Platforms, and Why Integration Quality Beats Feature Lists
Most platform teams that launch embedded payments hit the same quiet problem. The integration works, the demo is convincing and the pricing is competitive, yet the customers already using the software do not switch on payments. The temptation is to add features. Our position is that this usually misreads the problem. Research from payments providers on small-business adoption points to a more ordinary barrier: the current process works well enough, and a platform has to give customers a reason, and a low-effort route, to change it. For a SaaS or platform business, inertia is the competitor you are really up against.
What the research says, and how far to trust it
The evidence behind this article is narrow, so we state it precisely.
Small-business payments research published by Adyen with Visa, and separately by Mastercard, found that embedded-payments adoption is held back by what the market intelligence we rely on summarises as "the current process works" inertia. The reading that follows is that, for SaaS and platform businesses, inertia is the main competitor to embedded payments, and that the quality of the integration matters more than stated appetite for digital tools.
Three cautions apply.
- The sources are payments providers. Both are commercially interested in embedded payments growing. That does not make the findings wrong, but it is a reason to read them as vendor-authored research.
- We have not checked the method. We have not reviewed sample sizes, sampling or how "adoption" was defined in the primary sources, and we do not quote any figure from them. Check those before you cite numbers in a board paper.
- Small businesses are not every platform customer. The research concerns small businesses. If your customers are mid-market or enterprise, treat the conclusion as a hypothesis to test, not a finding.
The rest of this article is our analysis. We mark where it goes beyond the research.
Inertia is the competitor
Product teams tend to benchmark against other embedded-payments offers: other providers' feature lists, pricing and onboarding. The research suggests the more relevant comparison is the customer's existing way of getting paid or paying someone else. That might be a card terminal, a bank transfer, an invoice chased by email or a separate payment provider the customer has used for years.
"The current process works" is a rational position. It encodes several things a platform rarely sees:
- the customer already knows how it behaves when something goes wrong
- reconciliation is already solved, however clumsily
- changing it means a period of doing both, and a risk of cash arriving late
- nobody inside the customer's business is accountable for improving it
A feature list does not address any of these. A longer list of payment methods or a new payout option answers the question "what can it do?" when the customer is asking "what will it cost me to change, and what happens if it goes wrong?"
Providers are also adding capability at speed. Mastercard's Global Money Platform, for example, offers fiat and stablecoin accounts through a single API, which the industry reading describes as platform consolidation. That is useful for platform builders, but it widens the range of what you could offer, not the reasons a customer has to start. More capability behind the API does not automatically change adoption inside your product.
Product, integration or inertia? A diagnostic for platform leaders
Platform leaders often see low take-up and cannot tell whether the cause is the product, the integration or inertia. The three look similar in a dashboard and need different responses. This is our framework, not a research finding. It is a way to separate the hypotheses before you spend a quarter on the wrong one.
Is it the product?
A product problem means customers who try payments find it does not do what they need: a missing payment method, a settlement time that does not suit their cash flow, a fee structure that does not fit their margins. The test is to look at customers who completed set-up and then stopped, and to ask them why. If a few reasons recur, it is a product problem. If most customers never reach set-up, it is not.
Is it the integration?
An integration problem means the capability exists but the route to it is too much effort. The test is to follow the journey from the moment a customer sees the offer to the first live transaction and count the steps, the hand-offs and the places where they leave your product. Every step that sends a customer to a separate portal, asks them to re-enter information you already hold or waits on a manual review is a candidate. If drop-off clusters at specific steps, the problem is the integration.
Is it inertia?
An inertia problem means customers understand the offer, the integration is acceptable, and they still do not act. The test is to look for customers who start and stall without a clear failure, who say the offer is "interesting", or who postpone. Inertia shows up as absence of urgency rather than as complaints. The remedy is not a better product. It is a trigger, a reason to change now, and a lower cost of doing so.
In practice you will find a mix, and the order matters. Fix integration friction first, because it inflates both of the others. A customer who finds the route difficult will report a product gap, and a customer who sees no urgency will use friction as the reason to wait.
Integration quality beats feature lists
The research reading is that integration quality matters more than stated appetite for digital tools. Our interpretation of what "quality" means in a platform covers five things. These are design principles rather than measured results.
It sits inside the workflow the customer already uses
Embedded payments work when taking or making a payment is a step in a job the customer is already doing, not a separate product to manage. If a customer sends an invoice from your software, the payment option belongs on that invoice. If a customer reconciles in your software, the settlement should arrive there. Anything that sends the customer elsewhere to complete the task adds a reason to stop.
It uses what you already know
A platform already holds the customer's business details, their transaction history and their relationships. Asking for that information again is the clearest sign that payments were bolted on. Prefill what you can, ask only for what regulation or the provider requires, and make it obvious why each question is asked.
It shortens the time to the first live transaction
Adoption is not set-up. It is the first real payment that goes through and arrives where the customer expects. Measure from the offer to that moment, and treat every hour and every manual step in between as a cost. Delays in verification, in particular, can turn a motivated customer into a stalled one.
It makes the money visible
Customers who rely on the current process are often comfortable because they can see where the money is. If an embedded flow hides payouts, fees or failures, they will return to what they can see. Show the status of each payment, the fee taken and the expected arrival, inside your product, in the language the customer uses.
It handles failure well
The first time a payment fails, a refund is needed or a dispute arrives, the customer learns whether the new process is as safe as the old one. Design those paths before launch: clear messages, a named place to get help and a route to resolve the problem without leaving your product.
Sequencing that wins adoption
Treating inertia as the competitor changes the order in which you launch. This sequence is our recommendation, and it is deliberately conservative.
- Pick one workflow where the current process hurts. Choose a job where the customer already feels delay or effort, such as being paid after sending an invoice or paying a supplier. Customers with a visible problem need less persuading.
- Make it the default path for new customers. It is easier to start with a payment step already in the flow than to ask an existing customer to switch. Where defaults are inappropriate, make the offer part of the natural next step, not a banner.
- Instrument the journey, not just sign-ups. Track each step from offer to first live transaction and to repeat use. Set-up is a vanity measure if activation does not follow.
- Remove friction before adding features. Each release in the first period should shorten a step, remove a field or clarify a status. Resist the feature backlog until the journey is smooth.
- Add capability when customers ask for it. Extra payment methods, faster payouts and new rails are easier to justify when adopters request them.
- Learn from the stall. Interview customers who started and stopped. Their reasons tell you whether the next investment is product, integration or a trigger for change.
What we do not know
The research base for this article is a single finding from payments providers, and we have not reviewed its method. We have no measured evidence on how large the effect is, how it varies by customer size, sector or country, or whether it applies to UK platforms in particular. The only search data we hold on "embedded payments" is low-confidence and comes from a tiny base, so we have not used it as evidence of demand. Treat the diagnostic and the sequence as an operating hypothesis, and test it with your own funnel data.
Where Innovify fits
Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance. The adoption problem sits where product design, integration and payments knowledge meet, which is why we bring fintech expertise to platform teams rather than treating embedded payments as a generic integration task.
Our Embedded Finance & Digital Wallets work helps businesses design and launch financial products inside their own platforms, and we design compliance in from day one so that verification and consent steps are built into the journey, not added at the end. As an implementation partner across multiple fintech platforms, we help brands find a fast, compliant route to launching financial products. If you want to test a first workflow before committing, Innovify AI Labs lets enterprise teams run several proofs of concept in parallel, test with real users and finish with a business case ready for funding.
Frequently asked questions
Why do platform customers not adopt embedded payments?
Research from payments providers on small-business adoption points to inertia: customers feel the current process works, so they do not switch unless the new route is clearly easier. In our view, integration friction makes inertia worse, because each extra step gives a customer a reason to wait.
Does integration quality matter more than features for embedded payments?
According to the market reading of provider research, integration quality matters more than stated appetite for digital tools. Our interpretation is that features answer what a product can do, while integration quality answers what it costs the customer to start. Both matter, but friction usually needs fixing first.
How do I tell whether low take-up is a product, integration or inertia problem?
Look at where customers drop out. If they complete set-up and then stop, investigate the product. If they leave during set-up or at hand-offs, investigate the integration. If they understand the offer and simply postpone, investigate inertia and the trigger for change. Expect a mixture and fix integration friction first.
Where should a platform start with embedded payments?
Start with one workflow where the current process already causes delay or effort, and put the payment step inside it. Make it the default path for new customers, measure the journey to the first live transaction and remove friction before adding features.
Can I rely on the research that says inertia holds back embedded payments?
Treat it as directional. It comes from payments providers with a commercial interest, and we have not reviewed the sample or method in the primary sources. Check those details before quoting any figure, and test the finding against your own customers' behaviour.
Conclusion
Embedded-payments adoption inside platforms often stalls because the current process works well enough, not because the product lacks features. For platform leaders, that means treating inertia as the competitor, separating product, integration and inertia before choosing a fix, and judging integration quality by how little it costs a customer to start. Launch inside one workflow, make the first live transaction quick and visible, and add capability only when adopters ask for it.
