Stripe Billing for Telehealth SaaS — Visits, Subs, Insurance, No Leak
Layer per-visit metering on top of subscriptions, keep PHI out of the processor, and stop revenue leaking through the gap between Stripe and payer remits.
The problem
Telehealth SaaS billing breaks in places generic SaaS billing does not. A single patient relationship usually carries two revenue streams at once — a recurring platform or membership fee and a per-visit charge that may be split between the patient and a payer.
Visit-state machine vs. metered billing
The per-visit side runs on a state machine more complicated than typical metered billing: a session can be scheduled, started, partially completed, abandoned, no-showed, or disputed, and only some of those states should bill. A Stripe meter event fired on a session-started signal is a meter event you will be issuing credit memos against six weeks later.
Payer remit timing skew
Insurance reconciliation throws timing off because the patient-responsibility portion is often estimated at the time of service and trued up weeks later when the ERA arrives. The invoice is finalized; the actual amount owed is still in flight.
PHI inside processor payloads
The data model itself is constrained — anything that looks like a patient name, MRN, diagnosis code, or appointment note cannot ride into the payment processor's webhook payloads or metadata without pulling that processor inside the HIPAA boundary, which it does not want to be inside. Convenience fields like "patient name in description" are convenient until they become a breach notification.
Most teams ship the subscription side first, then bolt per-visit charges on top, and discover six months in that their revenue report is two spreadsheets glued together by an analyst at month end.
What changes for your business
A telehealth-aware Stripe architecture treats the processor as one half of a two-system contract. Stripe holds the recurring subscription, the metered per-visit prices, and the patient-responsibility charges — anything where the financial transaction itself is the artifact. Your EHR or scheduling system holds the clinical identifiers and the visit ledger. Between them sits a thin reconciliation layer.
Combined subscription plus metered visits
Subscriptions and per-visit charges show up in the same view because they live on the same Stripe customer with the same metadata schema. One Stripe subscription per customer carries a flat recurring price for the platform component and one or more metered prices for per-visit categories that map to your service taxonomy.
Visit-state machine gates meter events
No-shows and partial sessions stop billing or partial-billing because the meter increments are gated on a visit-completion signal your state machine owns, not on a Stripe event. The rule for "this visit counts" lives in one place and can be audited.
Memo-based payer reconciliation
Late payer remits land cleanly because a scheduled reconciliation job joins Stripe charges, payer ERAs, and the visit ledger on a stable internal visit ID, then posts adjustments as new memos against that token rather than reopening the original invoice. Audit history stays clean and downstream consumers do not re-fire on mutations.
Idempotent webhooks across the retry window
Webhook retries stop double-charging because every handler checks a dedup table keyed on event.id inside the same transaction that applies the side effect. The dedup record outlives Stripe's three-day retry window.
PHI-blind processor payloads
The architecture keeps Stripe outside the HIPAA boundary by routing only Stripe-generated fields plus opaque internal tokens through metadata, with the consumer rehydrating clinical context from BAA-covered systems on its own side. The billing system stops being a source of revenue leak and starts being something the finance team trusts on the first of the month.
What gets shipped for telehealth-specific billing
The work for a telehealth SaaS at this intersection lands in a predictable shape, even though the specifics depend on the EHR and the payer mix. A combined subscription model goes in first — one Stripe subscription per customer carrying a flat recurring price for the platform component and one or more metered prices for per-visit categories that map to your service taxonomy. Meter Events get posted from a single chokepoint in your backend, downstream of the visit-state machine, so the rule for "this visit counts" lives in one place and can be audited.
Webhook handlers ship next, written to be safe under Stripe's three-day retry window. Each handler verifies the signature, looks up the event.id in a dedup table, applies its side effect inside the same transaction, and writes the event.id on success. The handlers receive Stripe-generated fields plus opaque visit tokens in metadata, and pull any clinical context they need from systems inside the BAA boundary — the handler itself stays blind to PHI.
The reconciliation layer ships last and matters most. A scheduled job joins Stripe charges, payer ERAs, and the visit ledger on the visit token, posts credit or debit memos for payer adjustments, and emits a clean revenue feed for finance. Dunning gets configured to respect clinician schedules and patient-billing norms rather than firing aggressive retry emails on a generic SaaS cadence. The deliverable is a billing surface that handles the cross-cutting concerns telehealth introduces — combined pricing, PHI-safe payloads, late payer reconciliation, retry-safe webhooks — without requiring the engineering team to think about any of them again after launch.
Proof this pattern lands
BoostFrame Enterprise AI runs seven production applications on a Stripe billing stack we built ourselves — including a dual-pool credit system with metered consumption, subscription tiers, and webhook reconciliation that has run without a duplicate-charge incident across the live customer base. BFEAI is not a telehealth product, and we do not pretend it is. What transfers is the architecture: the combined subscription-plus-metered model, the idempotent webhook discipline, the dedup-keyed-on-event.id pattern, and the scheduled reconciliation job that keeps the ledger and the processor in sync. The telehealth-specific work — the PHI boundary, the payer remit timing, the visit-state machine — is the part we architect against your existing compliance regime, not something we bring in pre-built. The author is Bill Fackelman, co-founder and CTO of BoostFrame Enterprise AI.
Outcomes you should expect
What this delivers
- Per-visit revenue stops leaking from no-shows, partial sessions, and miscategorized place-of-service rates.
- Subscription MRR and per-visit cash flow show up in the same revenue view instead of two reports stitched together by hand.
- Webhook handlers stay idempotent under retries, so reconciliation runs do not double-invoice when payer ERAs arrive late.
Industry data
By the numbers
Stripe usage-based billing requires that customer usage be recorded with Meter Events and is billed in arrears at the end of the period, which forces telehealth teams to reconcile visit counts before invoice finalization.
Stripe retries failed webhook deliveries with exponential backoff for up to three days, so a deduplication store keyed on event.id must outlive the full retry window or late retries will double-charge.
45 CFR 164.501 defines 'payment' under HIPAA to cover billing, claims management, and collection — meaning visit-level identifiers leaving an EHR for a processor are PHI unless the processor sees only the minimum necessary financial fields.
CMS pays the non-facility rate for telehealth claims billed with POS 10 (patient's home) and the lower facility rate for POS 02, so a single visit's net revenue can shift based on a metadata flag the billing system has to capture at the time of charge.
Live in production today
The same engineering, shipped in production at BFEAI.
I'm co-founder & CTO of Be Found Everywhere (BFEAI), a 7-app AI SaaS platform running today. The work I deliver for clients is the work I do every week on my own platform.
7
Production apps
200K+
Keywords generated
1,500+
AI scans run
7,000+
Sites automated
Common questions
What buyers ask before reaching out
Can Stripe be used for telehealth billing at all if Stripe will not sign a BAA?
Yes, inside a narrow lane. Under the HIPAA financial-transaction carve-out you can use Stripe to collect payment as long as no PHI enters Stripe's systems — meaning no patient names, dates of birth, diagnosis codes, or clinical notes in metadata, descriptions, or webhook payloads. The visit identifier you send to Stripe should be a random token your EHR can resolve back to a patient on its own side, never an MRN. The architecture decision is keeping the processor on one side of the boundary and the EHR on the other, with a thin reconciliation layer between them.
How do we combine a monthly subscription with per-visit charges on the same customer?
Stripe supports a subscription with both a flat recurring price and one or more metered prices on the same item. The recurring component covers your platform fee; the metered components ride on Meter Events your backend posts as each completed visit clears its post-session checks. Stripe aggregates the meter readings and bills them in arrears at the period boundary. The hard part is not the Stripe config — it is the rule that decides what counts as a completed visit, because that rule has to handle cancellations, no-shows, and disputed sessions before the meter increments.
Insurance payments arrive weeks after the visit. How do we keep Stripe revenue and payer remits in sync?
Treat Stripe as the system of record for patient-responsibility dollars only, and your claims pipeline as the system of record for payer remits. Reconciliation runs as a scheduled job that joins Stripe charges, payer ERAs, and the visit ledger on a stable internal visit ID — not on patient identifiers. When a payer adjusts a claim, the job posts a credit or debit memo into Stripe rather than mutating the original invoice, which keeps audit history clean and avoids re-triggering webhooks downstream consumers may have already processed.
What goes in webhook payloads if PHI is not allowed?
The minimum the processor itself produces — event type, Stripe object IDs, amounts, currency, timestamps — plus whatever opaque identifiers your backend put into metadata when it created the underlying objects. A clean pattern is a visit_token UUID in metadata that your EHR can look up internally. The webhook consumer treats the payload as untrusted and pulls full context from systems that are inside the BAA boundary. The webhook never sees patient names, diagnoses, or appointment notes.
How do you stop duplicate charges when Stripe retries a webhook?
Persist every processed event.id in a deduplication table and check it inside the same transaction that applies the side effect. Stripe retries with exponential backoff for up to three days, so the dedup record has to live longer than that — a 7-day TTL is a safe floor. The same handler should be safe to run twice with the same event.id and produce identical state on the second run, which is what idempotency actually means in practice.
Does the place-of-service distinction (POS 02 vs POS 10) need to live in Stripe metadata?
It should live in your visit ledger as a first-class field because it changes the net revenue per visit. Whether it also rides into Stripe metadata depends on how you want to report — some teams pass a non-identifying POS code into metadata so Stripe-side reports stay useful, others keep Stripe blind to it and join on the visit token at report time. Either is workable; the choice is about where you want your revenue analytics to run.
How long does a billing architecture like this typically take to stand up?
For a telehealth SaaS already on Stripe with a working subscription product, layering metered visit billing plus the reconciliation job is typically a few weeks of focused work — most of it spent on the visit-state machine and the dedup-and-retry semantics, not on Stripe API calls. The slower variable is usually how clean the visit completion signal is inside the EHR or scheduling system. If that signal is ambiguous, the project sizing shifts toward that side of the boundary.
Ready to see if this is a fit?
A 15-minute call. No deck, no slides. We talk about what you're shipping and where engineering is the bottleneck. Either way, you walk away with a senior engineer's read on your situation.