Software companies spend months building embedded payments. They negotiate processor agreements, integrate APIs, train the sales team, and build a product they're proud of. Then adoption stalls at 15 or 20 percent of the customer base.
This is not a hypothetical. It's the median outcome for ISVs that launch payments without a deliberate activation strategy. And the frustrating part is that the problem rarely has anything to do with the product. The payments feature itself is often fine. The failure is almost always upstream — in how merchants are asked to adopt it, in the friction they encounter when they try, and in the incentive structure that's asking them to change something that already works.
This article breaks down the real reasons merchants don't convert to embedded payments — not the surface-level explanations, but the structural ones — and offers a framework for addressing each.
Reason 1: They Already Have a Processor They Trust
For many of your merchants, payment processing is a solved problem. They have a relationship with a processor, a terminal they know how to use, and a rate they negotiated three years ago. It's not optimal, but it's theirs.
Asking them to switch means asking them to trust a new provider for something that touches their revenue directly. That's a high-stakes request. Processors have burned merchants before — with unexpected holds, sudden rate increases, and support teams that disappear when chargebacks spike. The merchant's instinct to stay put isn't irrational. It's pattern-matched caution from real experience.
What actually works:
Don't lead with the switch. Lead with the pain their current setup creates. Reconciliation time. Deposits that don't match invoices. Running a report in the processor's portal and another one in your software because the data doesn't sync. The pitch isn't "our payments are better." It's "you shouldn't have to manage two systems for one business."
When you make the problem concrete, the solution sells itself.
Reason 2: The Onboarding Ask Is Too Heavy
Most embedded payments onboarding flows were designed by engineers who understand KYC compliance, not by product people who understand merchant attention spans. The result is a form that asks for a business EIN, a bank account number, the last four digits of an owner's SSN, a voided check, and a photo ID — before the merchant has any idea whether the feature is worth it.
Every field you add to the boarding flow is a percentage point of drop-off. Treat it like a checkout funnel, not a compliance checklist.
Merchants abandon long boarding flows for the same reason consumers abandon shopping carts: each step is a decision point, and enough decision points eventually produce a decision to stop. The fact that your processor requires the information doesn't mean you have to collect it all at once in a single form.
What actually works:
Progressive boarding. Collect what you need to get the account open. Get them processing on a small transaction. Collect the rest as you go. Some processors support phased onboarding natively. Others require you to build it yourself. Either way, the activation lift from reducing upfront friction is consistently one of the largest levers available.
For merchants in your vertical who are lower risk, explore whether instant approval workflows are available. The difference between "you'll hear back in 2–3 business days" and "you're approved" is not incremental. It's the difference between activation and abandonment.
Reason 3: They Don't Understand What They're Signing Up For
Most merchants don't understand interchange. They don't understand what a basis point is. They definitely don't understand what "interchange plus 30 basis points" means compared to "2.75 percent flat." And they are deeply, justifiably suspicious of any payment arrangement that they don't fully understand.
The default response to confusion is inaction. If a merchant can't quickly calculate whether your rate is better than what they have today, they won't switch. Not because your rates are worse — in most cases they're not — but because they can't tell.
What actually works:
Build a simple comparison tool. Show them what they paid last month and what they would have paid with you. Not in basis points. In dollars. "Based on your volume, you would have saved $340 last month" is a message that requires no financial sophistication to evaluate.
If you don't have access to what they currently pay, ask them to input their current rate and calculate it for them. The act of building this tool forces your team to internalize the economics, which is a side benefit you'll use in every merchant conversation afterward.
Reason 4: The Sales Team Isn't Selling It
This one is uncomfortable but true. Embedded payments adoption at most ISVs correlates more closely with whether the sales team is actively promoting it than with any product attribute. And sales teams don't promote things they don't understand, don't believe in, or don't get credit for.
If payments is mentioned as a footnote at the end of a demo — "oh, and we also have payments built in" — adoption will be footnote-level. If it's framed as a core workflow solution with a clear before-and-after, adoption looks different.
What actually works:
Solve the knowledge problem first. Your sales team needs to be able to explain the economics in plain language, run a basic savings calculation on the spot, and handle the three most common objections cold. That's a training and enablement investment, not a messaging problem.
Then solve the incentive problem. If the rep gets quota credit for the software sale and nothing for payments activation, you've told them where to spend their time. Commission structures that reward payments adoption — even modestly — change behavior consistently and fast.
Reason 5: The Product Doesn't Make the Case
The final reason is the hardest to hear: sometimes merchants don't adopt because the integrated experience isn't noticeably better than what they have.
If switching to your embedded payments means they get payments in the same interface as their software — but reconciliation still requires manual effort, reports still don't cross-reference properly, and tipping or surcharging still requires a workaround — then the value proposition isn't strong enough to justify the switching cost. You've built integration, not workflow improvement.
What actually works:
Audit the post-payment experience, not just the payment acceptance experience. Where does money movement data need to go in your software? What does the merchant have to do today to reconcile a day's deposits against invoices? What's their end-of-month close process look like?
The stickiest embedded payments implementations are the ones that eliminate work the merchant was doing anyway — not just the ones that consolidate where they swipe a card. If your payments feature can close a reconciliation loop that currently requires 45 minutes of manual work, that's your pitch. Not convenience. Recovered time.
The Number That Should Keep You Up at Night
Take your current payments adoption rate. Multiply it by your average merchant GMV. That's your current payments revenue base.
Now apply that same adoption rate to your total merchant base. The gap between those two numbers is your activation opportunity — the revenue you're already entitled to, in merchants who already pay you, who already trust you enough to run their business on your software.
No new product. No new customers. Just a more deliberate approach to getting existing customers to use a feature you've already built.
That math, done honestly, is usually the most compelling thing in any payments strategy conversation. Run it before your next planning cycle.
The Margin Labs Embedded Payments Playbook covers every model in detail — economics, implementation costs, decision frameworks, and the math behind the margin. Get the Playbook →