Subscription Billing for Telehealth: The Parts That Break at Month Two

Subscription billing demos beautifully. You wire up a payment provider, charge a card monthly, and the first cycle runs clean.

Month two is where it gets interesting. And month two is when the edge cases arrive all at once, because that's the first time renewals, failures, pauses, and cancellations all happen in the same week.

Here's what actually breaks, roughly in the order you'll meet it.

Failed payments are the biggest silent leak

A meaningful share of recurring card charges fail. Expired cards, insufficient funds, banks declining something that looks unusual, cards reissued after a fraud alert.

Most of these are not customers trying to leave. They're customers whose card changed and who have no idea the charge failed.

If your system treats a failed charge as a cancellation, you're losing patients who wanted to stay. What you need instead:

• Retries on a sensible schedule, not five attempts in an hour. Something like day 1, day 3, day 5, day 7.
• A card updater service through your payment provider, which handles reissued cards automatically. This alone recovers a good chunk of failures with zero human involvement.
• Actual messaging to the patient, through more than one channel. An email that lands in spam is not a notification. For care that involves medication, a text is appropriate.
• A grace period. Cutting off access to care the moment a charge fails is bad medicine and bad business.

Getting this right is usually worth more than any acquisition work you could do with the same effort.

Refills and billing cycles are not the same thing

This is where telehealth diverges from every SaaS billing tutorial you'll read.

Your subscription might be monthly. The prescription might be a 90-day supply. The consult might be required quarterly. Shipping might be every eight weeks.

These do not line up, and if you build assuming they do, you get patients who are billed but haven't been shipped anything, or shipped medication they haven't paid for.

Model the cycles separately from the start. Billing period, refill schedule, consult requirement, and fulfillment are four distinct clocks. Trying to collapse them into one is the single most expensive mistake in this space, because unwinding it later means migrating live subscriptions.

Pauses will be requested, so build them

Patients travel. They have a supply built up. They want to stop for a month without losing their history and their provider relationship.

If your only options are "keep paying" or "cancel," people cancel. Then they don't come back, because coming back means re-doing intake.

A pause needs to answer: how long, what happens to their access, when does billing resume, and what happens to a scheduled refill during it. Decide these deliberately rather than discovering them through support tickets.

Cancellation is a design problem, not a dark pattern

Make it findable and make it work in the account, without an email or a phone call.

Two reasons, one principled and one legal. The principled one: hostile cancellation flows generate chargebacks and public complaints, and chargebacks are worse for you than churn. The legal one: US regulators have been increasingly active on subscription cancellation being as easy as sign-up, and healthcare gets extra scrutiny.

What you can reasonably do is ask why on the way out, offer a pause as an alternative, and make sure they know what happens to any scheduled care. That's not a dark pattern. Burying the button is.

Proration and plan changes

Someone upgrades mid-cycle. Someone downgrades. Someone changes from monthly to quarterly.

Decide your policy before you build, because these need to be consistent and explicable to a support agent:

• Do upgrades take effect immediately with a prorated charge, or at the next cycle?
• Do downgrades take effect immediately or at renewal?
• What happens to a consult or refill already scheduled under the old plan?

There's no universally right answer. There is a wrong outcome, which is two patients in the same situation getting different results because the logic wasn't decided.

Receipts, records, and what patients ask for

Patients need documentation more often than typical subscription customers — for HSA and FSA reimbursement, for their own records, sometimes for insurance.

Make invoices downloadable from the account. Include enough detail to be useful, and be careful about what clinical detail belongs on a receipt that gets emailed. A superbill with diagnosis codes is a different document from a payment receipt, and they should be handled differently.

Where the compliance line sits

Your payment provider handles card data, and that keeps card numbers out of your systems entirely. That part is well-solved.

The part people get wrong is everything around it. Your billing records connect a person to a treatment. A subscription named "Monthly HIV PrEP Plan" appearing in an emailed receipt, a customer support tool, or your analytics is a disclosure of health information.

Practical guidance: keep clinical specificity out of billing descriptors, out of email subject lines, and out of anything a third-party tool can see. Your support team needs enough to help and no more.

Build this before you launch, not after

The list that actually matters before you take the first payment:

• Retry logic with a card updater
• Multi-channel failed payment notifications
• A grace period that doesn't interrupt care
• Pause as a real option
• Self-serve cancellation
• Billing cycles modeled separately from refill and consult cycles
• Downloadable invoices
• Clinical detail kept out of billing metadata

Every one of these is dramatically cheaper to build up front than to retrofit onto live subscriptions with real patients attached to them.

---

We build subscription billing, intake, and scheduling for US telehealth companies on BAA-covered infrastructure. See the full picture.