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. The hard part is solving all four together, which is how telehealth founders can end up bouncing between generic processors that decline them 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 card industry's baseline of technical and operational requirements for protecting payment account data. 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 being boarded under a health-care merchant category code (MCC) or, for merchants outside those codes, running an Inventory Information Approval System (IIAS) that identifies eligible items — the two routes IRS guidance allows for flexible-spending and health-reimbursement cards.
• LegitScript-aware underwriting. Visa classifies some merchant types as high-integrity risk and requires the acquirer to register those merchants with Visa before it submits their transactions (Visa Core Rules, §1.9.5.1). LegitScript says Visa and Mastercard recognize its certification for card-not-present approvals, which is why underwriters of DTC-medical, pharmacy-adjacent telehealth, and prescriber-credentialed platforms often look for it or an equivalent compliance posture. Mass-market processors can decline these platforms on their merchant category 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 long 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_id the 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.

At Von Payments, card data is tokenized in our PCI DSS Level 1 vault and never touches the merchant's server, and our payment endpoints can be configured to keep PHI separate from payment metadata. We sign BAAs where the integration architecture warrants one — our telehealth payments page says to raise it with our compliance team during onboarding.

// 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 over the following days, escalate to dunning if not recovered, suspend after a grace period. Customer-experience math says don't over-suspend because the lifetime value of a recovered subscriber justifies generous retry windows.

Recurring care plans 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 faster than a software subscription would — clinical-continuity windows are tighter than software-SaaS windows. Network tokens head off some declines in the first place, because a token can be updated automatically when a card is reissued; 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. Flexible-spending and health-reimbursement cards are issued through the patient's employer, so a job or plan change can mean a new card. The path-of-least-friction card update — a hosted card-update link sent over the channel the patient already uses — is usually a quicker way back to a working card than an elaborate dunning sequence.

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 the money is meant for medical care as the tax code defines it (IRS Publication 969). For FSA and health-reimbursement (HRA) cards, IRS rules limit where the card can be used (Notice 2006-69); with an HSA, the account holder must keep records showing the money went to qualified medical expenses (Publication 969). The acceptance question for the merchant has two layers:

1. Is the merchant registered under a health-care MCC? IRS guidance limits FSA and HRA cards to merchants and providers with health-care-related merchant category codes (Notice 2006-69) — for example Visa's 8011 (doctors and physicians), 8021 (dentists and orthodontists) and 8099 (medical services and health practitioners not elsewhere classified) (Visa Merchant Data Standards Manual). At a merchant without a health-care MCC that hasn't implemented IIAS, the card must be declined (SIGIS). The acquirer assigns the MCC that most accurately describes the business during merchant boarding (Visa Core Rules, §1.5.1.11) — the merchant can't change it transaction-by-transaction.
2. Does the merchant need IIAS? IIAS (Inventory Information Approval System) is how a merchant outside the health-care MCCs can accept these cards: its system checks each item purchased against a list of eligible items and approves only those (Notice 2006-69). Drug stores and pharmacies must run IIAS unless a store qualifies under the IRS's 90% rule (Notice 2007-2). According to SIGIS, the industry body that sets the IIAS standard, a telehealth merchant operating under a medical MCC is not required to implement IIAS (it may choose to if it also sells eligible over-the-counter products), while one operating under a pharmacy MCC must — and prescription fees have to be charged separately, not bundled with consultation, membership or subscription fees (SIGIS). Under Visa's rules, a merchant using IIAS-based auto-substantiation must be certified by SIGIS (Visa Core Rules, §5.8.14.3).

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 the merchant sells under a pharmacy code or sells eligible products. Processors that don't know telehealth boarding can set merchants up under a generic software or retail MCC, where FSA and HRA cards decline, and fixing it means going back to the acquirer.

At Von Payments, we support HSA/FSA acceptance for eligible medical services through standard MCC routing, and eligible-item identification and IIAS compliance are part of underwriting setup.

// UNDERWRITING

LegitScript-aware acquirer routing — the structural friction

For many telehealth platforms, the reason they leave their first processor isn't pricing or downtime — it's underwriting. Acquirers that don't underwrite these categories may decline DTC-medical, pharmacy-adjacent, and prescriber-credentialed platforms on their merchant category, or accept them initially and then back out when the platform's actual transaction mix surfaces. The result can be months 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, state pharmacy licensing where applicable, and direct-to-consumer marketing language. Standard underwriting reviews don't always go to this depth; telehealth-aware underwriting does.
• Acquirer relationships with banks that take the category. Some acquiring banks underwrite telehealth and DTC-medical categories and others don't. Working relationships with the ones that do — not just integration capability — are what get a telehealth platform approved and kept.
• Documentation collected upfront, not after the fact. LegitScript certifications, state pharmacy licenses, prescriber credentialing records, documentation for any FDA structure/function claims in product marketing — 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.

At Von Payments, underwriting reviews LegitScript-equivalent compliance posture, state pharmacy licensing where applicable, and prescriber credentialing for platforms that prescribe, and VERA, our AI onboarding assistant, routes the application to the acquirer in our network most familiar with telehealth and digital-care models. Those acquirers expect the documentation upfront, so onboarding moves faster when it's prepared (telehealth payments).

// 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 + MDES so saved cards can update automatically when a bank reissues them — chronic-care subscribers don't lapse because their card got rotated by their bank.
3. Telehealth-tuned retry + dunning with 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 banks that underwrite the merchant's specific telehealth profile, with documentation collected upfront so approval isn't deferred.
6. Chargeback management tuned for clinical-services dispute patterns — the evidence behind a clinical-services dispute is different from 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 several processors in their first 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's requirements apply to the covered entity (the telehealth platform or the clinical practice) and, where the rules say so, to its business associates — no single vendor in the stack can make the covered entity compliant. What a payment processor can do is be HIPAA-aware: design integration patterns that don't force PHI through the payment infrastructure, sign business associate agreements (BAAs) where the integration warrants one — the satisfactory assurances a covered entity must obtain before a vendor handles PHI on its behalf — 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, and HIPAA's administrative-simplification provisions don't apply to an entity's activities authorizing, processing, clearing or settling payments for a financial institution, 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: many telehealth founders spend 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 (often LegitScript-aware underwriting, since that's the blocking one for launch) and discovers the others as they bite.

The shortcut is a processor that already handles the telehealth-specific requirements together. Our telehealth industry page describes how Von Payments does it: network tokenization with a PCI DSS Level 1 vault and BAA-eligible integration patterns that keep PHI out of the payment path, plus HSA/FSA card acceptance, LegitScript-aware underwriting for DTC-medical and pharmacy-adjacent platforms, smart retry, and a dunning workflow. Or talk to underwriting if you want to walk through a specific platform's requirements.