Embedded Payments, Reconsidered: When the Built-In Pitch Is the Wrong Answer

Somewhere in the last eighteen months, payments became the new monetization frontier for healthcare software vendors. ModMed has ModMed Pay. Tebra paired up with Stripe. Planet DDS launched Planet DDS Pay. Oracle folded Oracle Payments directly into their healthcare stack. The list grows every quarter.

This is the "embedded payments" trend, and it's one of the bigger structural shifts happening in healthcare payments right now. A 2026 ProviderPay survey by FinMed Partners and Adyen found that 32% of independent practices already use some form of embedded payments. The embedded finance sector in healthcare is projected to grow 30% a year, hitting $21 billion by 2029.

On paper, the pitch is hard to argue with. Fewer vendors, less admin overhead, payments baked into software your team is already logged into. For a single-location dermatology practice or a small dental office, the tradeoff usually pencils out.

For PT clinics, behavioral health practices, and RCM companies, it gets more complicated. And the complication is worth understanding before your next software renewal.

What "Embedded" Actually Means (and Who It Benefits)

Embedded payments means your software vendor has built payment processing directly into their platform. Instead of using a separate payment gateway, processor, or billing tool, everything happens inside the same system.

What makes this trend so aggressive is the business model behind it. When a software company embeds payments, they earn revenue on every transaction that flows through their platform. A McKinsey analysis of ISV maturity models notes that software platforms pursuing embedded payments shift from being a partner to effectively competing with standalone payment processors, keeping a larger share of the transaction economics for themselves.

That's not inherently bad. It can create a simpler experience. It can reduce the number of vendor relationships to manage. The question is whether the simplification comes at the cost of functionality, flexibility, and pricing transparency.

Where Embedded Payments Break Down in Healthcare

The embedded model works cleanly when billing is straightforward: one patient, one visit, one charge, one payment. It starts to strain in any of the following situations.

Consider a PT clinic where billing involves both insurance and self-pay simultaneously. A patient has a $40 copay at the time of service, insurance covers a portion of the visit, and three weeks later the patient owes a remaining balance that wasn't clear during their appointment. Collecting across these different stages, from different sources, at different times, requires a payment system that handles post-adjudication billing, balance notifications, and flexible payment options. An embedded checkout designed primarily for point-of-sale card swipes often isn't built for that multi-stage workflow.

Behavioral health billing has similar structural challenges but different specifics. A single patient's care may be funded by a combination of commercial insurance, Medicaid, and family out-of-pocket contributions. Coverage churn tends to run high, especially in populations dealing with substance use disorders where insurance status can change mid-treatment. The payment system needs to adapt to shifting payer mixes without manual intervention, and a generic embedded solution built for stable single-payer billing tends to miss the mark.

RCM companies face a third variation. A billing service handling payments for dozens of provider clients deals with different fee structures, different bank accounts, different reporting requirements, and different patient populations across every client. An embedded payment tool that lives inside one EMR instance doesn't scale across a multi-client operation. RCM companies need payment infrastructure that's platform-agnostic and configurable at the client level.

Senior living and long-term care add yet another layer. A single resident's monthly charges may need to be split across a spouse, multiple adult children, and sometimes a trust, with each guarantor receiving their own statement at their own preferred delivery channel. Layer in autopay enrollment per guarantor, ancillary service consolidation (transportation, beauty services, personal care supplies on the same statement as the room rate), and the multi-state legal complexity of convenience fees, and you've moved well past what an embedded payment tool bundled with an EHR was designed to handle.

In any practice where billing context is sensitive, the detail level required is usually more than an embedded solution offers. Behavioral health is the clearest example. A statement that says the wrong thing, arrives at the wrong address, or reaches the wrong family member can damage the therapeutic relationship or violate patient trust. The payment experience in these settings needs to be configurable from statement content down to delivery method and guarantor-specific communication preferences.

The Vendor Lock-In Question

There's a practical concern that doesn't get discussed enough: when your EMR or PM vendor controls your payment processing, switching costs go up across the board.

The FinMed Partners / TrustCommerce whitepaper describes how payment options in healthcare are heavily influenced by which EMR is in use. Some platforms publish open specifications that let any gateway integrate (Epic is the primary example). Others connect directly to a single payment processor, meaning the provider's options are limited to what the vendor supports.

If you're locked into an embedded payment system and your software vendor raises processing fees, changes terms, or deprioritizes features you rely on, your options are limited. Switching payment processors means either finding a workaround outside the embedded system or switching the entire EMR, which is a far larger and more disruptive decision.

An independent gateway or payment partner, by contrast, can typically work across multiple EMR platforms and acquiring banks. That flexibility means you can change processors, negotiate rates, or adapt to new requirements without replacing your entire software stack.

What to Ask Before Saying Yes

If your software vendor is pitching embedded payments, these are the questions worth asking before you commit.

What happens to my processing rates in year two? Many embedded payment launches offer introductory pricing to drive adoption. Understand what the rate structure looks like after the promotional period ends, and whether you'll have leverage to negotiate.

Can I use a different processor if I need to? If the answer is no, you're accepting vendor lock-in on a service that directly affects your cash flow. Understand the tradeoffs before you agree.

Does this handle my full billing complexity? If your practice involves multi-stage billing (copay at time of service, insurance adjudication, then patient balance collection), make sure the embedded system supports the complete workflow, not just the point-of-sale transaction.

Who owns the patient payment data? If you ever switch software platforms, can you take your tokenized payment data, autopay enrollments, and payment history with you? Or does that data stay with the vendor?

What's the support model for payment issues? When a transaction fails, a refund needs processing, or a patient disputes a charge, who handles it? Some embedded models route payment support through the software vendor's general support team, which may not have specialized payment expertise.

The Real Question Isn't "Integrated or Separate"

The embedded payments trend is real, and the underlying principle is sound. Payment processing should be tightly connected to the clinical and billing systems that generate the charges. Nobody benefits from disconnected systems that require manual reconciliation.

The distinction that matters is between integration and control. A specialized payment partner that integrates with your EMR gives you the connected workflow without giving up flexibility, pricing leverage, or the ability to handle complex billing scenarios. An embedded solution your software vendor controls gives you simplicity in exchange for all of those things.

For a straightforward single-specialty practice with one location and simple billing, that tradeoff may be worth it. For PT clinics handling insurance and self-pay together, behavioral health practices navigating sensitive billing and coverage churn, and RCM companies serving multiple provider clients, the complexity of the billing usually demands a payment partner that specializes in it rather than a general-purpose tool bundled with the software.

It's a decision worth making with open eyes, not one that should be settled in a vendor renewal meeting.