Telehealth Payment Processing in 2026: Card-Not-Present Visits, Membership Care Plans, and HSA-FSA Acceptance

Call Bridge Capital Partners at 866-305-6454 now to review a telehealth payment flow, merchant-account structure, or gateway setup.

A virtual visit can lead to several different payment transactions

A telehealth appointment is remote. So is the payment only if the patient pays through a portal, app, phone call, or later invoice. Each channel creates different authorization records, stored-credential needs, and dispute evidence.

The payment channel does not change the care delivered. It does change what the merchant must document.

Payment path	What the patient does	Operational focus
Patient portal	Enters payment details in a web page	Secure page design, clear amount, receipt, and protection of browser-delivered payment fields
Telehealth app	Pays in an embedded or linked checkout	App and gateway integration, script controls, and separation of payment data from clinical data
Phone or virtual terminal	Gives payment details to a representative	Staff permissions, accurate entry, call-recording controls, and clear one-time or recurring consent
Invoice after the visit	Follows a payment link or pays an invoice	Invoice accuracy, patient recognition of the merchant, payment authorization, and reconciliation

A good design starts by mapping each route. Then identify which business accepts the card, which entity provided the care, and which party handles billing questions, refunds, and disputes.

For broader remote-payment controls, see Bridge’s card not present payment processing resource.

Explain the business model clearly during underwriting

Telehealth is not automatically a high-risk business. But an application may receive closer review when it combines card-not-present transactions with regulated services, recurring plans, prescription-adjacent offerings, or complex arrangements among a platform, clinic, and provider.

The acquiring bank needs to understand what the business actually does. It may ask who makes the clinical decisions, who contracts with the patient, who collects payment, and who is responsible for the care plan. It may also ask where providers are licensed, how appointments are delivered, what the refund policy covers, and which entity appears on the patient’s statement.

Do not describe a clinical service as generic software if the business also provides or arranges care. Do not assume that a software platform and the clinic can share one merchant account simply because the same app schedules the visit and collects payment.

A well-prepared application should identify:

• The legal entity or entities involved.
• The services each entity provides.
• The party the patient understands to be selling the service.
• Which entity accepts and receives the payment.
• How the platform, clinic, and provider share responsibilities.
• The channels used to take payment.
• How cancellations, refunds, and patient questions are handled.
• How the business manages care-plan billing and follow-up visits.

A complex card-not-present model may need a high risk merchant account designed around its actual operations. Account fit depends on underwriting. No particular classification or approval should be assumed.

Decide who is accepting the payment

When a platform hosts the visit and a separate clinic delivers care, the payment arrangement deserves particular attention. Avoid treating “merchant of record” as a label that resolves the question by itself. The practical arrangement matters.

Document whether the platform:

• Collects payment for its own service or on the clinic’s behalf.
• Sets the price or merely displays the clinic’s price.
• Receives settlement or routes funds to the clinic.
• Issues receipts and handles refunds.
• Owns the patient relationship for billing purposes.
• Resolves complaints about payment or service delivery.

The clinic should also document its role. The acquiring bank and processor need accurate information about the parties and flow of funds. A contract may allocate responsibilities between the platform and clinic, but the patient-facing checkout, agreement, receipt, and transaction data should tell a consistent story.

If one entity bills while another provides care, make the relationship understandable before charging the patient. Confirm the account structure with the acquirer before launch.

Match the checkout channel to the authorization record

A patient paying in a portal can review the amount and merchant identity before submitting. A patient paying by phone may rely on an employee’s explanation and entry. An invoice sent after a completed visit may need to show what the balance relates to without exposing unnecessary health details.

For each channel, keep a reliable record of the payment request, the amount, the patient’s action or authorization, the transaction result, and the receipt or confirmation. Restrict unnecessary patient and card data from notes, email, analytics, support tickets, and call recordings.

The payment record should contain enough information to support operations and a later inquiry. It should not become a second clinical chart.

Use descriptors patients can recognize

A patient may see a charge after a visit and not recognize the platform’s legal name, a clinic’s DBA, or a payment facilitator’s name. That confusion can lead to a “merchant not recognized” dispute even when the patient received care.

Plan the descriptor before processing begins. Confirm which name appears on the card statement and how the platform and clinic are represented. Use patient-facing language, website terms, receipts, and support contacts that match that arrangement.

Visa’s Merchant Data Standards Manual says merchant information should enable cardholder recognition and that merchant data must be accurate and consistent. Mastercard’s Rules also address merchant identity and transaction data. Ask the acquirer which name and descriptor format apply to the specific account structure. Do not promise a particular statement format until it is confirmed.

Treat care-plan billing as a consent process

A membership may cover access to a care team, scheduled follow-ups, or other defined services. The billing agreement should describe what the patient is buying and how charges will occur.

Before saving a payment credential, disclose the merchant name, the recurring schedule, the amount or method used to calculate it, the start date, the cancellation process, and any conditions that can change the charge. Keep the terms visible at enrollment. Record the patient’s affirmative agreement, the version of the terms, and the time and channel of consent.

A stored card is not unlimited permission to charge. A care-plan agreement should not silently expand into billing for unrelated visits or balances. If a future charge falls outside the original authorization, obtain the required consent before processing it.

For a follow-up visit charged to a card on file, distinguish between a patient-initiated payment and a later merchant-initiated charge. Mastercard defines credential-on-file transactions by reference to the cardholder’s express authorization to use a stored credential. Confirm the appropriate network indicators and processing rules with the acquirer or gateway.

Build a process for:

• Updating an amount or recurring schedule.
• Communicating material changes before they take effect.
• Stopping billing when a patient cancels.
• Handling a missed appointment under the terms the patient accepted.
• Updating an expired or replaced credential through a secure method.
• Documenting refunds, credits, and billing corrections.

Bridge’s merchant account features page describes recurring billing and virtual-terminal capabilities. Confirm the configuration and terms available for the specific account before relying on any feature.

Check HSA and FSA card acceptance for the virtual-care model

HSA and FSA cards are not a blanket determination that a particular charge is tax-qualified or eligible under a plan. The medical service, merchant classification, card program, and substantiation process all matter.

For a telehealth provider, begin with the business that is actually accepting payment. A licensed provider or clinic may be classified differently from a technology platform, wellness company, or billing intermediary. Do not choose a merchant category code solely to seek a higher rate or improve benefits-card acceptance.

Visa’s current Merchant Data Standards Manual describes MCC 8099 as Medical Services and Health Practitioners, not elsewhere classified. It is a residual code. The manual also lists more specific medical categories, including MCC 8011 for doctors and physicians. The acquirer assigns the code that best describes the merchant’s business. A telehealth service should not assume that 8099 applies just because care is delivered online.

The IRS’s Notice 2006-69 describes how certain health FSA and HRA card programs can use healthcare-related merchant category codes and other substantiation methods. It also describes an Inventory Information Approval System (IIAS) that can evaluate qualifying items at participating merchants. That is an inventory-based method. It should not be confused with a general guarantee that any telehealth service will qualify for a benefits-card payment.

In practice:

• Confirm the acquirer-assigned MCC for the entity accepting the payment.
• Ask the processor and relevant card administrator how healthcare cards are handled.
• Do not promise that a charge will be accepted or that a service is eligible for tax treatment.
• Provide an accurate receipt that identifies the provider, date, general service description, and amount.
• Keep HSA and FSA rules distinct. Plan substantiation and card authorization can differ.
• Give patients a way to ask their plan administrator about a declined transaction.

MCC classification can influence card routing and authorization, but it does not determine whether a patient’s particular service is a qualified medical expense. This article is not tax advice.

Track provider location and service delivery across state lines

Telehealth can involve a patient in one state, a provider in another, and a platform or billing team elsewhere. Cross-state licensure and service-delivery arrangements may affect operations and underwriting.

Maintain an accurate record of where providers are authorized to practice, where patients are located for a visit, and how the business determines whether the provider can deliver the service. Keep the application, website, patient terms, and operational records consistent.

This is not a legal determination about licensure. Requirements depend on the service and jurisdictions involved. Consult qualified counsel and relevant licensing authorities. For payment underwriting, disclose the actual operating footprint rather than relying on a broad statement that the service is “available nationwide.”

Prepare for virtual-care disputes with operational evidence

A service-not-rendered dispute can be difficult when the platform records a completed visit but the patient challenges the charge or says the service was not received. A platform’s “completed” status is useful evidence, but it may not answer every question.

Preserve a clear, privacy-conscious record of the transaction and service workflow. Depending on the case and applicable privacy requirements, relevant records may include:

• Appointment booking and confirmation.
• The agreed service and price.
• Patient check-in or attendance status.
• Visit start and completion timestamps.
• Provider assignment or session status.
• The payment authorization and receipt.
• Cancellation, refund, or rescheduling records.
• Patient communications about the charge.
• The billing entity and descriptor shown to the patient.

A patient’s dissatisfaction with the clinical outcome is not the same question as whether a payment was authorized or a visit took place. Avoid treating a completed platform status as the only evidence. Route clinical complaints through the appropriate care process and payment disputes through a controlled billing workflow.

Limit any dispute submission to information reasonably needed to respond. Health information is sensitive. Use the organization’s privacy and compliance procedures to decide what may be shared.

Clear cancellation and refund rules can prevent confusion. Explain what happens when a patient cancels, misses a visit, or needs to reschedule. If a refund is due, process it promptly and retain the confirmation.

Protect an embedded payment page

An embedded checkout can make payment convenient inside a telehealth app. It can also introduce third-party scripts and browser-level security considerations.

PCI DSS v4.0.1 includes two relevant requirements:

• Requirement 6.4.3 concerns payment-page scripts. The entity must authorize scripts, assure their integrity, and maintain an inventory with a justification for each script.
• Requirement 11.6.1 concerns detecting unauthorized changes to security-impacting HTTP headers and payment-page contents as received by the consumer’s browser. The mechanism must alert personnel and run at least every seven days, or at the frequency established through a targeted risk analysis under the standard.

PCI SSC’s guidance explains that these controls address payment-page security, including pages affected by embedded payment frames. An iframe or hosted checkout can reduce exposure to raw card data, but it does not automatically remove all merchant responsibilities. Determine the applicable PCI scope with the acquirer or qualified assessor.

For a telehealth application, inventory scripts that support payment, scheduling, chat, analytics, or other page functions. Limit scripts to what is needed. Document owners and purposes. Monitor changes. Route alerts to staff who can investigate and respond.

Keep clinical data and payment credentials separate wherever possible. Use a processor-hosted page or hosted fields if suitable. Return a token or transaction reference to the telehealth system rather than copying full card data into clinical records, application logs, or analytics.

Use ACH where it fits the business relationship

ACH may be useful for clinic-to-platform settlements, business invoices, or other business-to-business payments. It is a separate payment method with its own authorization, return, and reconciliation procedures. Do not treat a card-on-file agreement as ACH authorization.

Document who is paying whom, the purpose of the transfer, the amount or calculation method, the timing, and the authorization. For recurring debits, ensure the agreement clearly covers the schedule and revocation process. Reconcile each transfer to the relevant clinic, invoice, or contract. Work with the processor on return handling and funding timing.

A patient invoice can offer ACH as an option where the account supports it. Make the payee and invoice clear, and confirm that the payment method is appropriate for the payer and transaction.

Bridge offers information about ACH payment processing for small business and payment gateway integration for businesses evaluating these workflows. Review transparent credit card processing pricing when comparing account structures. Confirm all quoted terms against the merchant agreement and pricing schedule.

Cross-state operations and what underwriters actually review

A telehealth operator can serve patients across many states while its clinical staff hold licenses state by state. That is normal for the industry, and underwriters know it. What they want to see is whether the operator can explain its own model clearly.

The underwriting question is not whether the operator holds a specific clinical license in every state it touches. That is a licensure and regulatory question outside the payment file. The underwriting question is whether the operator can describe, in writing, how it operates: which clinicians are employed versus contracted, which entity sells the service to the patient in each state, and how the operator restricts scheduling when a patient is located in a state where the assigned clinician is not authorized to practice.

Three documents answer most of that review. A state-coverage matrix showing where providers are authorized and where the operator deliberately does not schedule. A clinical staffing summary describing the W-2 and contractor mix and who supervises whom. A short description of the prescriber arrangement where prescriptions are part of the service, including which entity employs or contracts the prescriber.

Prepare those materials before applying. Operators that assemble them only after an underwriting documentation request tend to produce inconsistent answers across the application, the website, and the patient terms, and inconsistency is what slows approval. Consistency across those three surfaces matters more than any single document.

This section is operational framing for an underwriting file, not legal advice. Licensure and telehealth-practice rules vary by state and change over time. Consult qualified counsel and the relevant licensing authorities for determinations.

Payer-adjacent flows and why some telehealth revenue is not card volume

Not all telehealth revenue runs through cards. A meaningful share can arrive as payer reimbursement, and that share never touches the merchant account.

The part that does run through cards is patient-responsibility volume: copays, deductibles, and amounts for services a plan does not cover. When an operator maps its expected processing volume for an application, it should separate patient-pay volume from payer volume before estimating average ticket or chargeback exposure. The two behave differently. Payer reimbursement arrives on a different timetable with different dispute mechanics. Patient-pay volume carries the authorization, descriptor, refund, and dispute dynamics described in the earlier sections.

This distinction also changes how payment methods should be assigned. Patient responsibility collected by invoice or ACH has its own authorization and dispute handling, separate from card-on-file portal payments. The ACH lane needs its own authorization records and should not inherit consent language written for stored cards. Operators that blend the two lanes tend to discover the gap when a payer-side collection is disputed through a channel that was never authorized for it.

For operators evaluating the ACH lane for patient invoices and clinic-to-platform settlements, Bridge's ACH payment processing for small business resource covers authorization and reconciliation basics. Confirm configuration with the processor before relying on it.

Assemble a telehealth pre-application file

Prepare records that explain both the clinical service and the payment flow. A complete file can help the acquirer understand the business without relying on assumptions.

Include:

• Formation and ownership documents for each legal entity.
• Provider names, credentials, and relevant license information.
• A description of services, care plans, and any prescription-adjacent activity.
• A clear explanation of the platform’s role and the clinic’s role.
• Platform-clinic contracts and patient-facing agreements.
• A walkthrough or screenshots of the app, portal, and payment pages.
• The expected channels: portal, app, phone, and post-visit invoice.
• Recurring billing terms, consent language, cancellation rules, and refund policy.
• A description of how completed visits and patient attendance are recorded.
• The proposed descriptor, receipts, and patient support contact.
• Processing statements and relevant processing history, if available.
• Expected transaction patterns, ticket range, and refund process.
• Gateway, processor, and software integration details.
• An overview of payment-data flows and systems that may contain health information.
• PCI documentation and vendor compliance materials relevant to the payment setup.
• The proposed MCC and confirmation from the acquirer.
• HSA/FSA acceptance requirements and the processor’s response.
• ACH authorization and reconciliation procedures, if ACH will be used.
• Cross-state operating information for provider and patient workflows.

The application should match the live experience. Update it if the business adds a membership, changes the billing entity, or launches a new payment channel.

Set the flow before the first charge

Telehealth operators should map payment collection to the service relationship. Identify the seller, care provider, payment recipient, and party responsible for billing support. Then match the payment channel to the correct authorization, descriptor, records, and dispute process.

Review stored-credential consent before charging for future visits. Confirm the MCC before seeking benefits-card acceptance. Keep payment-page scripts controlled. Keep payment data out of clinical systems where possible. Document ACH flows separately from card payments.

For context on adjacent healthcare billing, not a substitute for telehealth-specific planning, review Bridge’s medical billing payment processing resource.

Official sources

• PCI Security Standards Council: PCI DSS v4.0.1
• PCI Security Standards Council: Payment Page Security and Preventing E-Skimming
• HHS Office for Civil Rights: HIPAA and Telehealth
• HHS Office for Civil Rights: HIPAA Security Rule
• Federal Reserve: Regulation II, Average Debit Card Interchange Fee
• Visa Merchant Data Standards Manual
• Mastercard Rules
• IRS Notice 2006-69

For covered debit transactions, the Federal Reserve describes the Regulation II interchange standard as $0.21 plus 0.05% of transaction value, with a possible $0.01 fraud-prevention adjustment when the issuer qualifies. The standard applies to covered issuers and transactions. It is not a guaranteed merchant processing rate.

Call 866-305-6454 to review telehealth payment processing, gateway options, account structure, or pricing.