Healthcare breaks the assumption every payment system is built on
Ordinary commerce assumes the seller knows the price, the buyer is the payer, and money changes hands at the point of sale. A healthcare encounter violates all three. The provider often does not know the final price when the service is delivered. The party paying most of it is not the person receiving care. And the patient's share is frequently not billable for weeks, until an insurer has decided what it is.
That gap is the whole problem. A retailer collects at checkout, with the customer present and motivated. A provider asks for money weeks later, from someone who has already received the care, may not understand the charge, and may reasonably believe insurance was meant to cover it. Collection rates fall sharply as a balance ages, and the balances are large: high-deductible plans have moved a substantial share of healthcare revenue from institutional payers, who pay reliably by electronic remittance, to individuals, who pay unreliably by card. Card acceptance is the last four seconds of a process whose difficulty lies upstream.
Payer mix, adjudication and the explanation of benefits
Three terms do most of the work in this market, and general-purpose payment vendors routinely misuse all three.
Payer mix is the distribution of a provider's revenue across commercial insurers, Medicare, Medicaid and self-pay patients. It determines reimbursement levels, days in accounts receivable, denial rates, and how much money arrives as a patient payment rather than an institutional one. A dermatology practice with heavy commercial coverage and a rural clinic with heavy Medicaid have almost nothing in common operationally, though both are described as taking payments.
Adjudication is what the insurer does with a claim: apply the contracted rate, deduct what the plan covers, and return a determination of what the patient owes. The billed charge is rarely what anyone pays; the allowed amount is. Until adjudication finishes, the patient's balance is an estimate.
The explanation of benefits, or EOB, is the statement the insurer sends the patient describing that determination. Its provider-side counterpart is the electronic remittance advice, the 835 file, which the billing system uses to post payments and flag denials automatically. Patients regularly mistake an EOB for a bill, which generates calls, disputes and delay.
Money therefore arrives in two streams with different timing, failure modes and tooling: an institutional stream governed by claims and remittance files, and a consumer stream governed by statements, portals and cards. A vendor handling only one is solving half the problem — fine, provided the buyer knows which half they bought.
Two different problems: revenue cycle and patient payments
Almost every disappointing healthcare payments purchase comes from conflating these two.
The patient financial experience is the other half: presenting a comprehensible bill, reaching the patient on a channel they answer, showing what insurance actually did, offering a payment plan, and taking the money. Its counterparty is a consumer and its measure is self-pay collection rate.
| Problem | Counterparty | Measured by | Example providers |
|---|---|---|---|
| Revenue cycle and claims | Insurers | Denial rate, days in A/R | Waystar |
| Patient financial experience | Patients | Self-pay collection rate | Cedar |
| Card and ACH acceptance | Card networks, banks | Cost per transaction, authorisation rate | Elavon, Global Payments, Stripe |
Waystar sits on the payer-facing side at national scale — eligibility, claim submission, remittance, denial recovery and patient billing across roughly 7.5 billion transactions and $2.4 trillion of gross claims a year. It is a clearinghouse and workflow platform first, with patient payment acceptance layered on. It reports client counts in bands starting at $100,000 of annual revenue per client, so a single-provider practice is not the profile it is priced or supported for.
Cedar attacks the other half only. It sits on top of an existing practice management or EHR billing system, pulls balances, and owns everything downstream: outreach, a plain-language explanation of the bill, real-time checks against payer deductible data across more than 250 payers and against health-benefit account balances covering a majority of the HSA market, and configurable payment plans. It is explicitly not a processor — Stripe appears in its documented payment stack — so it adds a vendor and a margin above processing rather than replacing one. If a provider's problem is processing cost rather than collection rate, Cedar is the wrong purchase.
HIPAA, business associates and the agreement you must have
Healthcare is the one vertical where the wrong payments vendor creates regulatory exposure rather than merely operational annoyance.
Whether a payments vendor needs one depends on what it touches, and the line is finer than most sales teams admit. A processor handling only a card number, an amount and a generic descriptor is arguably handling financial data. The moment the payment record carries a patient identifier tied to a service, a procedure description, an account number resolving to a visit, or a statement image, protected health information is in the system. Patient billing platforms, statement vendors, portals and anything that messages a patient about a balance are squarely in scope; Paymentus, for instance, states it is subject to HIPAA as a business associate in healthcare contexts.
The mistake most practices make is assuming a signed BAA equals compliance. It does not; it allocates responsibility. Check three things before signing: that obligations flow down to the vendor's own subcontractors, including any processor or messaging service beneath it; that outreach content is controlled, since SMS and email is where protected health information leaks and is separately governed by the Telephone Consumer Protection Act; and what happens to the data at exit, because return-or-destruction terms are ignored until a migration makes them urgent.
Card data brings a second regime in PCI DSS. A provider taking cards at the front desk, in a portal and over the phone has three channels to scope, and phone payments keyed by staff into a practice management system are the most common source of unnecessary PCI scope.
HSA and FSA cards, and why the merchant category code decides whether they work
Health savings accounts and flexible spending accounts pay for a meaningful share of patient responsibility, and they are the clearest illustration of why healthcare acceptance is not generic acceptance.
An HSA or FSA card is a payment card issued against a tax-advantaged benefit account whose funds may only be spent on qualified medical expenses. The restriction is enforced at authorisation, and it is enforced against the merchant's classification. If a provider is boarded under a health-related merchant category code, the transaction is permitted. If the account was miscoded as general services, professional services or retail — which happens routinely when an account is opened by a generalist salesperson — the benefit card declines at the counter, and neither the patient nor the front desk can see why.
Substantiation matters too: benefit administrators may ask patients to document that a charge was qualified, so itemised receipts and clear statement descriptors reduce a support burden that otherwise lands on the practice.
Why general-purpose processing fits healthcare badly
Stripe, Square and Helcim are good products. For a direct-pay practice — concierge medicine, aesthetics, most dental, cash-pay therapy, veterinary — where the patient is the payer and the price is known at the time of service, general-purpose acceptance is the right answer, and buying a healthcare platform would be waste. Helcim publishes its interchange-plus margins openly and accepts HSA and FSA cards, a reasonable fit for a small clinic billing no insurance.
The fit breaks the moment claims enter the picture. A general-purpose processor cannot check eligibility before the visit, produce a pre-service estimate, submit a claim, ingest an 835 remittance file, post an insurer payment against a patient balance, or tell a patient why they owe what they owe. It will take a card beautifully against a balance nobody has explained, which is precisely the transaction patients dispute.
- Balances are lumpy. A $15 copay and a $3,800 deductible balance are the same product to a processor and entirely different problems to a practice. Percentage-based card economics make large balances expensive to accept, which is why ACH or bank debit belongs in the mix for the big ones, and why payment plans rather than one-time checkout are the core patient payment product.
- Fee pass-through is constrained. Surcharging and convenience fees are limited by card network rules and by state law. Assume the provider absorbs processing cost unless counsel says otherwise.
- Portability. Stored credentials, saved payment plans and enrolled autopay patients are the real switching cost. Ask before signing whether tokens can be migrated to another processor and on what terms.
Two providers deserve naming as clear misfits, because both surface in healthcare payment searches. InvoiceCloud is a capable biller-direct bill presentment platform, but it markets to utilities, local government, county tax and insurance only; it once owned the healthcare payments business HealthPay24 and healthcare no longer appears in what it sells, so a provider evaluating it is shopping in a market the vendor deliberately exited. Paymentus lists healthcare and acts as a HIPAA business associate, but it is a bill presentment and payment platform for high-volume recurring billers rather than a merchant acquirer or revenue cycle system, and its own filings state that its services do not involve the movement of funds directly. For a hospital wanting one bill-pay channel across many obligations that can work; for a practice wanting claims, statements and card acceptance in one system, it does not.
Where card acquirers actually fit
The acceptance layer still has to come from somewhere, and two mainstream acquirers have bought their way into healthcare specifically.
Elavon, the merchant acquiring arm of U.S. Bank, acquired Salucro Healthcare Solutions in 2024 and now sells patient billing and payment alongside card acceptance, with recurring and stored-credential billing through its gateway products; U.S. Bank states Elavon ranks in the top five for healthcare. The trade-off is contractual rather than technical. Elavon's published terms of service set an initial three-year term that renews automatically for successive two-year terms, require funds to remain available for at least 180 days after termination, and allow terms to change on 30 days' notice with continued processing treated as acceptance. Diarise the non-renewal notice window on the day you sign.
Global Payments has built and bought vertical software across healthcare, education, parking and property management, and sells payments through those platforms rather than standalone. Healthcare is a supported vertical rather than the capability it leads with, and the company has spent a decade absorbing acquisitions — Heartland, TSYS, EVO, and Worldpay in January 2026 — each of which moved merchants between platforms and support structures.
A workable shortlist depends on which problem dominates:
- Insurance-billing practice with a denial and A/R problem: start on the claims side. An RCM and clearinghouse platform such as Waystar is the anchor purchase, and acceptance follows it.
- Health system with sound claims operations and poor self-pay collection: the patient experience layer is the gap, and a specialist such as Cedar is built for that, on top of the existing billing system.
- Direct-pay or cash-pay practice: a transparent general-purpose processor, with the merchant category code verified for HSA and FSA acceptance.
- Multi-site group buying acceptance and patient billing from one vendor: a healthcare-specialised acquirer such as Elavon, with term, renewal notice and post-termination hold read line by line first.
Four questions belong in every evaluation before price: will the vendor sign a BAA and flow the obligations to its subcontractors; can it post an 835 remittance automatically into the billing system; what merchant category code will the account be boarded under; and can stored payment credentials leave with the practice. A vendor answering all four cleanly is rare enough that the answers filter better than the quote.
Frequently asked questions
What makes healthcare payment processing different from retail?
In retail the seller knows the price, the buyer is the payer and money moves at the point of sale. In healthcare the final price is unknown until the insurer adjudicates the claim, most revenue comes from a payer who is not the patient, and the patient's share becomes billable weeks after the service. That delay is why healthcare collection rates are structurally lower, and why patient billing, payment plans and a clear explanation of the balance matter more than checkout speed.
Do I need a HIPAA business associate agreement with my payment processor?
You need one with any vendor that creates, receives, maintains or transmits protected health information on your behalf. A processor handling only card data, amounts and a generic descriptor may not be in scope, but any vendor presenting a patient statement, sending billing messages, running a patient portal or holding balances tied to a visit almost certainly is. Ask the vendor directly, get the agreement in writing, and confirm its obligations flow down to its own subcontractors.
What is the difference between revenue cycle management and patient payments?
Revenue cycle management is the process of getting paid by insurers: eligibility verification, coding, claim submission, remittance posting, denials and appeals, measured by denial rate and days in accounts receivable. Patient payments is the consumer-facing problem of presenting an understandable bill and collecting the patient's share, measured by self-pay collection rate. They require different software, and buying one while expecting the other is the most common mistake in healthcare payments procurement.
Why do HSA and FSA cards decline at my practice?
Because acceptance of health benefit cards is enforced against the merchant category code assigned when the payment account was opened. If the practice was boarded under a general services or retail code rather than a health-related one, the benefit card is declined at authorisation regardless of what the patient is paying for. Check the merchant category code on your merchant statement; correcting it requires the acquirer to reboard the account.
Can a medical practice use Stripe or Square?
For a direct-pay practice where the patient is the payer and the price is known at the time of service, yes, and a healthcare-specific platform would be unnecessary. For a practice that bills insurance, no general-purpose processor can verify eligibility, submit a claim, ingest an 835 remittance file or post an insurer payment against a patient balance, so it solves only the final step. Verify that the merchant category code supports HSA and FSA acceptance either way.
Should patients pay large balances by card or by bank debit?
Card economics are largely percentage-based, so a large deductible balance is expensive to accept by card while a small copay is not. Offering ACH or bank debit for large balances alongside cards for small ones materially reduces the cost of collecting the same revenue. Because surcharging and convenience fees are restricted by both card network rules and state law, most providers absorb processing cost and should design the payment mix accordingly.
Are utility and insurance bill payment platforms suitable for healthcare?
Generally not. InvoiceCloud markets to utilities, local government, county tax and insurance only, and no longer sells into healthcare despite having previously owned a healthcare payments business. Paymentus does list healthcare and acts as a HIPAA business associate, but it is an electronic bill presentment and payment platform rather than a merchant acquirer or revenue cycle system, so it addresses bill delivery and collection rather than claims, remittance or patient responsibility.