HIPAA-Aware Payment Routing: Designing a Compliant Vault for Telehealth Subscriptions

// FRAMING

Telemedicine is four payment problems wearing one merchant hat

A telehealth platform — virtual-first clinic, DTC medical, chronic-care subscription, behavioral-health practice — asks its payments stack to solve four problems simultaneously. Each is solvable in isolation. Almost no mainstream payment processor solves all four together, which is why telehealth founders end up bouncing between generic processors that auto-decline at onboarding and specialty processors that don't know what HIPAA-aware tokenization is.

The four problems are:

• PHI / PCI separation. Protected health information lives under HIPAA. Card data lives under PCI-DSS. The two scopes have overlapping but distinct technical requirements, and a careless integration ends up either dragging PHI through PCI infrastructure or dragging card data through clinical systems — both compliance failures.
• Recurring care plans. Membership telemedicine, chronic-care subscriptions, behavioral- health retainers — all run on recurring billing against saved cards. Recurring billing has its own decline-rate failure modes (card expiration, soft declines, vault drift) that compound the higher- regulatory environment.
• HSA / FSA card acceptance. Patients want to pay with their health-savings card for eligible medical services. That means MCC routing, IIAS (Inventory Information Approval System) compliance for eligible-good identification, and issuer-side recognition of the merchant as a healthcare merchant.
• LegitScript-aware underwriting. Most tier-1 acquirers will not underwrite DTC-medical, pharmacy-adjacent telehealth, or prescriber- credentialed platforms without LegitScript certification or the equivalent compliance posture. Standard mass-market processors decline at the MCC level long before the integration question matters.

This guide walks through how to handle all four in one architecture — what to demand from the vault layer, how HSA/FSA routing actually works, why recurring care plans need a slightly different retry strategy than generic subscription billing, and how to navigate the underwriting fit problem without a six-month sales cycle.

// THE VAULT

Decoupling clinical metadata from the payment vault

The single most important architectural decision in a telehealth payments stack is keeping clinical metadata out of the payment vault. The temptation is to attach patient identifiers, diagnosis codes, prescription references, or appointment IDs to the transaction record on the payment side — convenient for reconciliation, but it pulls PHI into the PCI scope and the PCI infrastructure into the HIPAA scope.

The clean pattern is to keep two parallel record sets that share only an opaque correlation identifier:

• Payment side — vault holds tokenized card credentials (network tokens via Visa Token Service and Mastercard MDES), payment intent metadata limited to amount/currency/timestamp, and an opaque correlation_idthe merchant generated. Nothing about the patient's identity, diagnosis, or care plan lives here.
• Clinical side— the merchant's clinical record system holds the patient identity, encounter notes, care-plan structure, and the same correlation_id mapped to the patient record. PHI never traverses the payment path.

The correlation identifier is the join key. When a payment lifecycle event arrives (capture, refund, chargeback), the merchant's back-office joins it to the clinical record on demand, in the merchant's own HIPAA-scoped infrastructure. The payment processor never sees the patient's identity, and the clinical system never holds raw card data.

This pattern requires the payment processor's vault to accept arbitrary opaque metadata without trying to parse it. Some processors helpfully “enrich” transaction metadata by surfacing customer information in reporting tools — fine for retail, a compliance problem for telehealth. The vault has to treat the correlation identifier as opaque, never display it as customer-friendly text, and never auto-resolve it against external systems.

For Von Payments, this is the design our vaultuses by default. The PCI-DSS Level 1 tokenization keeps card data out of the merchant's servers; the correlation- identifier model keeps clinical context out of the payment vault; and we sign BAAs where the integration architecture warrants one (talk to compliance during onboarding for the specifics).

// RECURRING CARE

Recurring care plans need a different retry strategy

Generic subscription billing assumes the customer is paying for software access. The retry strategy is tuned for that: soft decline, retry in 24–72 hours, escalate to dunning if not recovered, suspend after seven days. Customer-experience math says don't over-suspend because the lifetime value of a recovered subscriber justifies generous retry windows.

Recurring careplans inherit none of those defaults. A chronic-care subscription pays for prescription refills, lab work, ongoing provider check-ins. When a card declines, suspending the membership doesn't just stop a software subscription — it can interrupt a prescription, miss a scheduled clinical event, or lapse an insurance authorization window. The customer-experience math is different. The clinical-continuity math is stricter.

The retry strategy for recurring care:

• Faster soft-decline recovery. Aim to clear soft declines in under 48 hours, not 72+ — clinical-continuity windows are tighter than software- SaaS windows. Network tokens reduce the soft-decline rate in the first place; smart retry handles what gets through.
• Real-time patient notification.When a card declines, the patient needs to know within hours — both to update the card and to receive any clinical-continuity messaging (e.g., “your upcoming refill may be delayed until billing is resolved”). Generic dunning email templates aren't calibrated for this; the dunning flow needs telehealth- specific language.
• Suspension extends a grace window for clinical actions.The financial side of the membership may suspend, but prescriptions in flight, scheduled appointments, and lab work that's already been ordered need to continue or unwind cleanly. The dunning system has to talk to the clinical system, which is where the correlation-identifier model pays off — the clinical system can look up the payment status and adjust care-plan posture without the payment system knowing anything about clinical context.
• Card-on-file updates take priority over recovery emails. Telemedicine subscribers tend to be older and more frequently moving health-savings accounts as employers change. The path-of-least-friction card update — a hosted card-update link sent over the channel the patient already uses (often SMS for older demographics) — recovers more memberships than elaborate dunning sequences.

See the recurring payment processing guide for the broader subscription-billing framework. Telehealth adds the clinical-continuity overlay on top of that framework, but doesn't replace it.

// HSA / FSA

HSA / FSA acceptance is an MCC and IIAS problem, not a card-data problem

Health Savings Accounts (HSA) and Flexible Spending Accounts (FSA) issue cards that look like regular Visa or Mastercard credit/debit at the surface, but issuer-side they restrict spending to IRS-eligible medical expenses. The acceptance question for the merchant has two layers:

1. Is the merchant registered under an eligible MCC?HSA/FSA cards approve at telehealth-eligible MCC codes (8099, 8011, 8021, etc.) and decline at most others. The MCC is set at the acquirer level during merchant boarding — the merchant can't change it transaction-by-transaction.
2. Is the transaction tagged as IIAS-eligible? For merchants that sell both eligible and ineligible services through the same account (e.g., a telehealth platform that does both medical visits and wellness coaching), the IIAS (Inventory Information Approval System) flag identifies which transactions on the account are eligible-good. Without IIAS, all transactions on the account are treated as ineligible-mixed, and HSA/FSA cards decline.

The implication: HSA/FSA acceptance isn't a feature the merchant turns on after the fact. It's an acquirer-side configuration that has to be set during onboarding, with the MCC matched to the merchant's actual offering and IIAS configured if mixed-eligibility is in play. Generic processors that don't know telehealth boarding tend to set merchants up under generic SaaS or healthcare-services MCCs that decline HSA/FSA, then can't change it later.

For Von Payments, HSA/FSA acceptance is configured during the same VERA-led onboarding flow that handles the rest of the telehealth-specific posture. The MCC routes are picked based on the actual service mix the merchant describes — and the IIAS flag is configured if and when the merchant's eligibility mix warrants it.

// UNDERWRITING

LegitScript-aware acquirer routing — the structural friction

The single biggest reason telehealth platforms churn from their first processor isn't pricing or downtime — it's underwriting. Mainstream tier-1 acquirers either decline DTC-medical, pharmacy-adjacent, and prescriber-credentialed platforms at MCC scan, or accept them initially and then back out when the platform's actual transaction mix surfaces during the first quarter. The result is a six-to-nine-month cycle of switching processors while the clinical operation is also trying to scale.

The fix is upstream of the integration question: route to acquirers who already underwrite the specific telehealth category before the merchant signs. This requires:

• LegitScript-equivalent compliance review at onboarding.Not just a yes/no checkbox — actual review of the platform's clinical model, prescriber credentialing posture, FDA pharmacy licensing where applicable, and direct-to-consumer marketing language. Standard underwriting reviews don't do this depth; telehealth-aware underwriting does.
• Acquirer relationships with wellness-friendly tier-1 banks. Specific acquiring banks have expanded their telehealth and DTC-medical policy over the last several years. Operating relationships with those banks — not just integration capability — is what gets a telehealth platform processing on tier-1 rates instead of specialty-acquirer rates.
• Documentation collected upfront, not after the fact. LegitScript certifications, state pharmacy licenses, prescriber credentialing records, FDA structure-function compliance documentation — the acquirers who underwrite telehealth expect to see all of this before approval. Onboarding flows that ask for it later guarantee a deferred-approval cycle.

The Von Payments approach to this is the VERAconversational onboarding. The relevant documentation is captured in chat — VERA asks the telehealth-specific questions during the application itself, and routes the application to the acquirer in our network most familiar with the platform's specific vertical. The underwriting decision comes back in hours instead of days for most telehealth profiles, and the merchant lands on a tier-1 acquirer relationship rather than being deferred to a specialty processor with worse economics.

// PUTTING IT TOGETHER

What the stack actually looks like

A working telehealth payments stack ends up with these properties, in order of architectural importance:

1. PCI-DSS Level 1 tokenization vault that accepts opaque correlation identifiers without parsing them. Card data never touches the merchant's clinical systems; PHI never touches the payment vault. BAAs available from the processor where the integration architecture warrants one.
2. Network tokens via VTS + MDESso saved cards stay valid through reissues — chronic-care subscribers don't lapse because their card got rotated by their bank.
3. Telehealth-tuned retry + dunningwith clinical-continuity messaging, faster recovery windows, and a card-update path that uses the patient's preferred channel.
4. MCC + IIAS configured for the actual service mix at onboarding, so HSA/FSA cards approve for eligible services without per-transaction configuration.
5. Acquirer routing to LegitScript-aware tier-1 banksfor the merchant's specific telehealth profile, with documentation collected upfront so underwriting decides in hours.
6. Chargeback management tuned for clinical-services dispute patterns — the dispute mix on telehealth has different reason-code distribution than DTC commerce, and the representment workflow needs to handle clinical-documentation evidence (treatment notes, prescription records, consent forms) without dragging PHI through the representment system.

None of these are exotic. Each one exists somewhere in the market. The hard part is having all six in one stack, with one onboarding flow, with one integration surface. Telehealth founders who've bounced between three or four processors over their first two years have lived the alternative.

// THE COMPLIANCE FOOTNOTE

What 'HIPAA-aware' means and doesn't mean

One language point worth being careful about: a payment processor cannot make a merchant HIPAA-compliant. HIPAA compliance is a property of the covered entity (the telehealth platform or the clinical practice), not of any single vendor in its stack. What a payment processor can do is be HIPAA-aware: design integration patterns that don't force PHI through the payment infrastructure, sign BAAs where the integration warrants one, and collaborate with the merchant's compliance team on architecture decisions that affect joint surface area.

Phrases worth being skeptical of when evaluating processors:

• “HIPAA-compliant payment gateway” — payment gateways don't hold PHI in normal operation, so the HIPAA-compliance claim has limited meaning. What matters is whether the processor will sign a BAA and what the BAA actually covers.
• “Healthcare-ready out of the box” — usually means MCC routing is supported, nothing more. The real telehealth-stack work (LegitScript, IIAS, clinical-continuity dunning) almost never comes “out of the box.”
• “Full-stack HIPAA solution” — at the payments layer, this is overreach. The processor is one vendor in a HIPAA-scoped operation; calling the processor itself “HIPAA-complete” misses what compliance actually requires.

What to look for instead: specific BAA language, specific MCC and IIAS handling, specific LegitScript underwriting posture, specific correlation-identifier metadata design. The processors that talk about those specifics are the ones whose architecture is actually thought through. The ones that lean on compliance-marketing language are usually one BAA conversation away from asking your compliance counsel to write the BAA for them.

// CLOSING

The telehealth-payments shortcut

The honest version: most telehealth founders will spend three to nine months figuring this stack out the hard way — switching processors, re-architecting card-data flows, re-negotiating acquirer placements, re-tuning dunning templates. The first attempt usually optimizes for one of the four problems (most often LegitScript-aware underwriting, since that's the blocking one for launch) and discovers the others as they bite.

The shortcut is to land on a processor that's already done the integration work for telehealth-specific requirements, with acquirer routing into wellness-friendly tier-1 banks already in place, with VERA-led onboarding that captures the LegitScript / FDA / prescriber documentation in chat rather than back-and-forth email. That's the case Von Payments is built for in this vertical — see our telehealth industry page for the product specifics, or talk to underwritingif you want to walk through a specific platform's requirements.