Collecting Patient Payments for Telehealth Visits: Pre-Visit Capture, Card-Not-Present Risk, and Refund Rules

For most telehealth patient payment collection workflows, the practice should obtain and securely tokenize a payment method before the appointment, collect a confirmed copay or fixed self-pay amount when appropriate, and avoid treating an uncertain deductible or coinsurance estimate as a final charge until reliable payer information or claim adjudication establishes the actual patient responsibility.

That distinction matters. Capturing a payment credential, obtaining permission for later use, estimating patient responsibility, authorizing a card transaction, and actually charging the patient are separate events. 

A well-designed telemedicine payment workflow keeps them separate so staff can collect known amounts promptly without turning an estimate into an unintended overpayment.

Telehealth Patient Payment Collection: The Practical Workflow at a Glance

A virtual visit removes the front-desk card terminal, but it does not remove the normal sequence of scheduling, financial disclosure, eligibility verification, service delivery, claim adjudication, and patient-balance reconciliation.

The practical goal is to move payment collection into the digital intake process without assuming that every patient’s responsibility is known before the visit.

Stage	What the Practice Can Do	Typical Use	Main Risk
Booking	Capture and tokenize a payment method; present financial policy	Self-pay visits, future patient balances, no-show policy	Charging before responsibility is established
Pre-visit check-in	Recheck insurance information and collect a known amount	Confirmed copay or disclosed fixed self-pay fee	Using stale or incomplete eligibility information
Immediately after visit	Charge a known amount under the patient’s authorization	Fixed-price self-pay encounter	Mishandling cancellations or failed connections
After claim adjudication	Reconcile and collect remaining responsibility	Deductible, coinsurance, adjusted patient balance	Longer collection cycle

These are workflow choices, not universal requirements. A behavioral-health practice offering a published self-pay video-session fee may reasonably use a different sequence from a multispecialty practice whose patient responsibility depends heavily on insurance adjudication.

The important operational question is not simply, “Can we collect payment before a telehealth visit?” It is, “What do we know about this patient’s obligation at this point in the workflow, and what did the patient authorize us to do?”

Practices developing their virtual collection process can also use a secure patient payment portal to separate patient-facing billing from manual card handling. The portal should complement—not replace—the practice’s financial policy and patient ledger.

Should You Charge at Booking, Check-In, or After the Telehealth Visit?

There is no single payment point that fits every telehealth encounter. The appropriate timing depends on whether the amount is fixed, reliably known, merely estimated, or dependent on insurance processing.

Charging at Booking

Charging at booking can work well for clearly priced self-pay services. If a practice publishes a fixed fee for a particular virtual service and the patient knowingly schedules on that basis, immediate collection may reduce later billing work and give both sides a clear financial expectation.

The tradeoff is refund administration. Appointments move, patients cancel, clinicians become unavailable, and technology sometimes fails. A practice that collects the full fee several days before every visit needs a disciplined system for voids, refunds, credits, and rescheduling.

For insured visits, booking is often a better time to capture a payment credential and obtain appropriate authorization for later use than to charge an amount that has not yet been established.

A card authorization also needs careful terminology. The patient’s contractual permission to use a stored payment method later is not the same thing as the processor’s real-time authorization of a specific card transaction.

Charging During Virtual Check-In

Virtual check-in is often the closest equivalent to front-desk collection.

The practice has an opportunity to confirm that the patient intends to attend, verify or update insurance information, display the current financial policy, confirm the stored payment method, and collect a known copay or fixed self-pay charge.

This timing can reduce some of the refund burden associated with collecting days in advance. It also gives staff an opportunity to resolve an expired card or billing question before the clinician joins.

Eligibility information still has limits. A response indicating a copay, deductible status, or benefit structure does not necessarily establish the final amount the payer will assign to the patient after processing the claim.

Charging After the Visit

Post-visit collection works particularly well when payment depends on whether the service actually occurred or when the final amount remains uncertain.

A fixed self-pay encounter might be charged immediately after successful completion. For an insured encounter involving deductible or coinsurance exposure, the practice may instead submit the claim and collect the final balance later.

The disadvantage is time. The longer the interval between care and payment, the more likely the practice is to need statements, reminders, portal messages, or staff follow-up.

Timing Model	Works Well When	Main Advantage	Main Caution
Booking	Price is fixed and disclosed	Earliest collection	More refunds and rescheduling adjustments
Virtual check-in	Copay or self-pay amount is known	Closely resembles front-desk collection	Eligibility may still change
Immediately post-visit	Service completion affects whether payment is appropriate	Confirms visit occurred first	Requires prompt payment workflow
Post-adjudication	Deductible/coinsurance is uncertain	Uses payer-determined responsibility	Slower patient collection

A mature workflow may use all four approaches. The practice can collect a self-pay fee at booking, a verified copay during check-in, and an adjudicated deductible balance later without treating those processes as contradictory.

A Recommended Telemedicine Payment Workflow From Booking to Reconciliation

A telemedicine payment workflow should follow the encounter rather than operate as a separate collection system.

1. Schedule the appointment: Create the appointment and assign the internal account or encounter reference the practice will use across scheduling, billing, and reconciliation.
2. Present the financial policy: Before requesting card-on-file permission, show the relevant payment, cancellation, no-show, refund, and balance-collection terms.
3. Collect or verify coverage information when applicable: Record insurance details and perform the practice’s normal eligibility workflow without treating eligibility as a guarantee of final benefits or payment.
4. Obtain appropriate payment-method authorization: Explain whether the credential is being saved for a particular visit, future patient balances, a payment plan, or another defined purpose.
5. Use tokenization rather than manually retaining card information where the platform supports it: With tokenization, the payment environment typically retains the payment credential and returns a substitute token the practice can reference. The practice should verify its actual architecture rather than assume every system works this way.
6. Display the amount accurately: Identify it as a confirmed copay, fixed self-pay price, estimated patient responsibility, or currently unknown balance.
7. Complete virtual check-in: Confirm patient identity according to practice procedure, appointment status, contact information, payer information, financial-policy acknowledgment, and payment method.
8. Process only the amount appropriate at that stage: A known $30 illustrative copay and an uncertain deductible estimate should not automatically be handled the same way.
9. Issue a receipt: Give the patient a clear record of the transaction without placing unnecessary clinical details in the payment description.
10. Associate the transaction with the encounter: Preserve the processor transaction ID, payment status, amount, timestamp, and internal encounter reference.
11. Submit an insurance claim when applicable: This article focuses on patient-pay collection; the claim matters here only because payer processing may change the patient’s final responsibility.
12. Reconcile the payer determination: Compare the allowed amount, payer payment, contractual adjustments, prior patient payment, and final patient responsibility.
13. Collect, credit, void, or refund the difference: The ledger should show exactly how the account reached its final balance.

This structure can be implemented in an EHR, practice-management system, revenue-cycle platform, patient portal, or integrated combination of systems. The technology matters less than preserving a clear audit trail from appointment to final balance.

Integrated systems can reduce the number of manual handoffs involved in that process; practices evaluating automation may find the discussion of linking payments with practice-management workflows useful when designing reconciliation procedures.

How to Collect Payment Before a Telehealth Visit Without Overcharging

To collect payment before a telehealth visit safely, staff need to distinguish five different concepts.

• Payment-method capture means obtaining the card or other credential through an appropriate payment interface.
• Tokenization generally means replacing sensitive card data with a substitute value that can be referenced for later transactions. It can reduce the practice’s exposure to raw card data, but tokenization does not automatically eliminate every PCI DSS responsibility.
• Future-use authorization means the patient’s permission for the practice to initiate future transactions under disclosed circumstances.
• An estimate is a projection of what the patient may owe. It is not automatically the patient’s final responsibility.
• A charge is an actual transaction that results in payment or, depending on transaction state, a pending amount against the patient’s account.

Illustration: known copay

Assume eligibility information for a scheduled virtual follow-up reports a fixed $30 copay, the practice considers that information sufficiently reliable under its normal workflow, and collection is permitted under applicable contracts and policies.

The practice might display: “Estimated amount due at check-in: $30 copay,” confirm the payment method, and collect the $30 during virtual check-in. The amount and workflow are illustrative, not a universal payer rule.

If later adjudication shows that the patient owed less, the practice needs a mechanism to apply the overpayment appropriately or refund it rather than leaving the account unreconciled.

Illustration: deductible uncertainty

Now assume the eligibility response indicates that the patient has deductible remaining, but the practice does not yet know the payer’s final allowed amount for the service.

A useful workflow may be to capture an authorized payment method before the visit, clearly communicate that the responsibility is estimated or not yet determined, submit the claim, and charge or request the remaining patient balance only after reliable information establishes it.

That protects the distinction between having a payment method available and claiming that a speculative amount is already owed.

Clear patient-facing estimates and explanations matter here. Guidance on making healthcare bills and estimates easier for patients to understand can help practices avoid language that makes estimates look final.

Card-Not-Present Healthcare Payments Work Differently From Front-Desk Card Transactions

Many telehealth payments are card-not-present (CNP) transactions because the payment credential is supplied remotely rather than read from the physical card through an in-office terminal.

That distinction affects both risk management and processing economics.

Issue	Card-Present Office Payment	Card-Not-Present Telehealth Payment
Card interaction	Card/device is physically read at terminal	Credential submitted online, through portal, by phone, or stored credential
Typical environment	Front desk or office	Remote patient
Authentication signals	Chip/contactless/terminal data may be available	Different remote-verification signals
Fraud exposure	Physical-card controls may apply	Remote credential misuse receives more attention
Useful controls	EMV/contactless and terminal safeguards	Hosted fields, tokenization, AVS/CVV where supported, fraud tools
Processing cost	Depends on agreement and transaction	May differ; depends on agreement and transaction

Actual pricing for card not present healthcare payments cannot be reduced to a universal percentage. Cost depends on the merchant agreement, card product, processing channel, transaction characteristics, card-network rules, gateway setup, and other factors.

For remote collection, useful tools may include a secure patient portal, hosted payment page or fields, tokenization, address verification service (AVS) where supported, and CVV collection for an appropriate transaction. These controls reduce certain risks; none guarantees that a transaction will not be disputed.

A payment link is generally preferable to asking staff to receive full card data through ordinary email, text, or free-form messages. The exact PCI scope depends on the architecture and how cardholder data flows through the practice’s systems.

Practices that need a broader distinction between healthcare privacy requirements and payment-card security standards can review how HIPAA and PCI DSS apply to different kinds of information.

Do Not Store CVV for Later Telehealth Charges

A card verification value—called CVV, CVC, CID, CAV2, or similar names depending on the payment brand—is commonly used during card-not-present authorization.

It cannot be retained for future transactions after authorization. The PCI Security Standards Council states that card verification codes are sensitive authentication data and may not be stored after authorization, including for card-on-file or recurring use.

That prohibition is different from storing or tokenizing an eligible payment credential through a compliant environment. A practice should not create a spreadsheet, EHR note, scanned form, call recording, or other workaround that retains the CVV for later telehealth charges.

How Card-on-File Consent Should Work in a Virtual Intake Flow

Card-on-file healthcare workflows are easiest to defend when the patient can tell what they have authorized without reconstructing several screens of fine print.

A practical digital intake sequence can work as follows:

1. Identify the medical practice or billing entity.
2. Show the relevant financial policy before the card authorization.
3. State what types of amounts might be collected—such as a known copay, fixed self-pay charge, adjudicated patient balance, or disclosed payment-plan installment.
4. Explain whether the amount is currently known, estimated, or determined later.
5. Explain the intended timing of charges.
6. Explain how the patient can update the stored payment method or contact the billing office with questions.
7. Present cancellation and no-show terms distinctly rather than burying them inside general card language.
8. Capture affirmative acceptance.
9. Record evidence such as policy version, date, time, account, and acceptance event.
10. Make the policy or an accessible copy available to the patient.

A practice should distinguish authorization to store or tokenize a payment credential from permission to initiate future charges. Technical ability to charge a token does not by itself answer whether a particular charge was authorized under the patient agreement, card-network requirements, merchant agreement, applicable law, or payer contract.

Likewise, a generic checkbox should not be assumed to satisfy every possible state, contractual, or network requirement. Policy language should be reviewed for the jurisdictions, payer arrangements, patient populations, and payment methods the practice actually uses.

This wording is deliberately general. A practice should have counsel or appropriate compliance personnel review its actual authorization language.

How to Handle Copays, Deductibles, and Coinsurance When the Exact Patient Amount Is Unknown

Insurance information can help a practice estimate what to collect, but eligibility and benefits information should not be mistaken for final claim adjudication.

Known Copay

A copay is often a fixed amount associated with a covered service under the patient’s benefit structure.

If current eligibility information identifies a copay that the practice reasonably treats as reliable, and advance collection is consistent with applicable agreements and policy, the practice may collect it during pre-service or virtual check-in.

Staff should still record that payment against the eventual encounter so it is accounted for when the payer processes the claim.

Deductible

Deductible information is more difficult operationally.

An eligibility response may show that the patient has deductible remaining, but that does not necessarily tell the practice exactly what the payer’s allowed amount will be for the eventual claim. Other claims may also affect accumulator information between eligibility verification and adjudication.

For that reason, “deductible remaining” and “amount this patient will owe for this visit” should not be treated as synonymous.

Coinsurance

Coinsurance is generally expressed as a percentage of an applicable amount under the patient’s plan.

Even if the percentage is known, the practice may need the payer-determined allowed amount and other claim information to calculate the final patient responsibility correctly. A pre-service number may therefore be an estimate rather than an established balance.

Uncertain Coverage or Coordination of Benefits

When coverage cannot be confirmed, insurance is changing, or coordination-of-benefits information is incomplete, staff should avoid creating artificial certainty.

The workflow may call for updating coverage information, explaining the practice’s self-pay or pending-insurance policy, obtaining a payment credential under appropriate authorization, and determining the final balance when the coverage issue is resolved.

Post-Adjudication Balance

After claim adjudication, the practice should reconcile:

• the billed charge;
• payer-allowed amount where applicable;
• payer payment;
• contractual adjustments;
• copay or other pre-service payment already received;
• deductible and coinsurance assigned to the patient;
• credits or prior payments;
• remaining balance.

Responsibility Type	What May Be Known Before Visit	What Can Remain Uncertain	Operational Treatment
Fixed self-pay fee	Published price	Cancellation/service-delivery exceptions	May be collected under disclosed policy
Copay	Often shown during eligibility	Eligibility changes or claim-specific issues	Collect when sufficiently confirmed
Deductible	Remaining accumulator may be shown	Final allowed amount and adjudicated responsibility	Treat pre-service figure carefully as estimate
Coinsurance	Percentage may be known	Dollar value until allowed amount is known	Estimate or wait for adjudication
Uncertain coverage	Limited information	Whether/how claim will be paid	Resolve information; avoid claiming certainty
Adjudicated balance	Payer determination available	Corrections/appeals may still occur	Reconcile prior payments before collection

Hypothetical example: A practice estimates $110 of patient responsibility based on available benefit information and receives a $40 pre-service payment. The eventual adjudication assigns $85 to the patient. The remaining patient balance is not another $85; the practice must account for the $40 already received before seeking the difference.

The figures are illustrative. Payer rules and contractual requirements differ.

Designing a Fair Telehealth No-Show Payment Policy

A defensible telehealth no-show payment policy begins before the missed appointment.

Patients should be able to find the cancellation window, applicable fee structure, method for cancelling, treatment of late arrivals, technology problems, rescheduling rules, and available exceptions before they authorize a payment method.

The policy also needs to distinguish a patient’s failure to attend from a practice’s failure to provide the appointment.

Situation	Typical Operational Response to Consider
Patient fails to join	Apply disclosed policy if permitted and facts support it
Patient cancels inside the stated window	Apply policy consistently, subject to applicable requirements
Patient is materially late	Follow the disclosed late-arrival/rescheduling policy
Clinician cancels	Prevent or refund patient fee associated with the cancelled appointment
Practice platform fails before care begins	Generally avoid treating the patient as a no-show
Brief patient connection issue	Attempt reconnection or rescheduling before classifying as no-show
Connection fails after meaningful care occurred	Review service delivered, billing status, policy, and rescheduling facts
Documented emergency	Apply the practice’s exception/waiver process

There is no universal no-show dollar amount that can be recommended for every medical practice. State law, payer contracts, program requirements, patient agreements, and other rules can affect whether a fee is permitted and how it may be applied.

Consistency also matters. If managers have authority to waive a fee because of emergencies or technology failures, the practice should define who may approve a waiver and document the reason.

A telehealth no-show payment policy should also make clear that a no-show fee is conceptually different from charging for a professional service. If no clinical service was delivered, the practice should not casually characterize a missed-appointment fee as payment for completed care.

Refund Rules for Dropped Connections and Clinician Cancellations

Telehealth creates refund situations that rarely arise at a physical front desk. A video session can fail before the clinician joins, after introductions, halfway through an assessment, or after nearly all appropriate care has been delivered.

A rigid “connection failed = refund” rule can therefore be as inaccurate as a rigid “appointment started = no refund” rule.

1. The clinician never joins

If the patient arrived as instructed but the clinician never provided the scheduled service, the practice should generally avoid imposing a patient no-show charge and should examine any advance payment for appropriate refund, void, credit, or rescheduling treatment.

2. The practice cancels

A patient should not normally bear a cancellation fee that was intended to address the patient’s failure to attend when the practice itself cancelled the appointment.

Any prepaid amount should be handled according to the financial policy and whether the patient chooses a refund, rescheduled service, or permitted credit.

3. The platform fails before care starts

If a practice-selected system or broader outage prevents the encounter from beginning, staff should document the failure and avoid automatically labeling the patient a no-show.

4. Connection fails within the opening minutes

Suppose the clinician and patient connect briefly, but a practice-side technical problem terminates the session before meaningful care can be completed.

The billing team should examine what service was actually delivered, whether the appointment was rescheduled, whether a claim has been or will be submitted, and what the disclosed financial policy says before retaining or refunding the patient’s payment.

5. Most of the clinically appropriate encounter occurs

A late connection failure does not automatically mean no service occurred. The practice should determine what professional service was actually furnished and coordinate the patient-payment decision with the coding/billing status rather than applying a technology-refund rule in isolation.

6. The patient voluntarily leaves

Staff should document what occurred rather than automatically classifying the event as either a no-show or a completed appointment. The facts may matter to both professional billing and any patient-payment policy.

7. The visit is rescheduled

Sometimes a credit to the rescheduled encounter is operationally cleaner than a refund followed by a new payment. Whether that approach is appropriate depends on the payment method, financial policy, payer circumstances, accounting treatment, and patient agreement.

Refund decision checklist

Before issuing, retaining, or converting a payment to credit, ask:

• Was clinical service actually delivered?
• Who or what caused the interruption?
• Was the encounter completed another way?
• Was it rescheduled?
• What did the patient-facing financial policy say?
• Was an insurance claim submitted?
• Has the claim already been adjudicated?
• Is the payment associated with a professional service, a no-show fee, or another charge?
• Would a credit be appropriate and acceptable instead of a refund?
• Has the transaction been reflected correctly on the patient ledger?
• Has the patient been told clearly what will happen?

A refund decision should never exist only inside the merchant dashboard. The patient account and encounter history must show the same financial result.

What Telehealth Payment Receipts and Card Descriptors Should Say

Remote transactions are easier to dispute when the patient cannot recognize the charge.

A card statement descriptor should therefore use a recognizable practice or billing identity within the capabilities and requirements of the processor and card network. Where supported, useful elements may include a recognizable name and patient-facing contact number.

A receipt can provide more context without becoming a miniature medical record.

Useful receipt elements include:

• practice or recognizable billing name;
• transaction date;
• amount;
• receipt or transaction reference;
• general service description;
• payment method displayed safely, such as masked information where appropriate;
• patient-facing billing contact information;
• refund or credit reference when relevant.

Safer descriptions include phrases such as “Virtual appointment payment,” “Patient balance payment,” or “Medical visit payment” when those descriptions are accurate.

Avoid putting a sensitive diagnosis, medication, condition, psychotherapy topic, or other unnecessary clinical detail into a descriptor simply to make the charge recognizable.

The goal is recognition without over-disclosure.

Connecting the Payment to the Encounter Without Sending Unnecessary PHI to the Processor

The cleanest architecture separates clinical context from payment execution.

Within the practice’s EHR or practice-management environment, staff may need the encounter ID, internal patient account, transaction ID, amount, timestamp, status, payer adjudication, and resulting balance. 

The payment processor may need enough information to authorize and settle the financial transaction, but it ordinarily does not need a copy of the clinical note simply because a patient is paying by card.

HIPAA permits covered entities to use and disclose PHI for payment activities, which include billing and collection, subject to applicable limitations. HHS also explains that, where the minimum-necessary standard applies, covered entities must make reasonable efforts to limit PHI to what is reasonably necessary for the intended purpose.

For payment-system design, the practical implication is to ask, “What does this component actually need?”

A processor transaction might be associated internally with encounter E-10472, for example, while detailed diagnoses and clinical documentation remain in the clinical system. The identifier example is fictional and contains no real patient information.

HHS’s guidance on the HIPAA minimum necessary requirement emphasizes reasonable limits on PHI uses, disclosures, and requests when the standard applies.

Payment processors and business-associate status require a functional analysis

It is inaccurate to say either that every payment processor must sign a business associate agreement or that payment processors can never be business associates.

HHS specifically states that when a financial institution performs ordinary consumer-conducted debit, credit-card, check-clearing, electronic-funds-transfer, or similar activity that directly facilitates a payment, the institution is providing its normal financial transaction service and is not acting as the covered entity’s business associate merely on that basis.

The analysis can change when a vendor performs additional functions on behalf of the covered entity that involve PHI. Examples might include certain billing, patient-account, data-management, hosting, or administrative functions depending on the facts.

Practices should evaluate what the vendor actually creates, receives, maintains, or transmits and what service it performs—not rely only on a marketing label.

The current HHS business-associate guidance includes the financial-transaction distinction business-associate guidance includes the financial-transaction distinction and explains when functions performed for a covered entity can create a business-associate relationship.

Payment Processor vs EHR: What Information Belongs Where?

A healthcare payment integration should not indiscriminately copy every field between systems.

Data	EHR / Practice System	Payment Processor
Patient clinical notes	Yes, as appropriate	Avoid for ordinary card processing
Diagnosis information	Yes, as appropriate	Avoid unless legitimately required for a separate supported function
Encounter ID	Yes	Minimal reference only if needed
Internal patient/account reference	Yes	Minimal reference if needed
Transaction ID	Yes	Yes
Amount	Yes	Yes
Timestamp/status	Yes	Yes
Card token	Reference where integrated	Typically maintained within payment environment
Raw card data	Avoid unnecessary local storage	Handle according to applicable compliant payment architecture
CVV after authorization	No	No
Payer adjudication details	Yes	Usually unnecessary for ordinary card settlement
Free-text clinical narrative	Yes, when clinically appropriate	Avoid

This table is an architectural guideline rather than a declaration that every EHR or processor works identically.

PCI DSS scope must be evaluated based on the real card-data environment. Tokenization can reduce exposure, but practices should not assume that the mere presence of a token removes every system, process, or staff activity from PCI obligations.

HIPAA and PCI DSS also address different problems. HIPAA applies to protected health information in covered situations. PCI DSS establishes payment-card data security requirements. Card-network operating rules, processor/acquirer contracts, and payer requirements form additional—and separate—layers.

Reducing Telehealth Payment Disputes and Chargebacks

No telehealth workflow can eliminate disputes, but it can make charges easier to recognize and easier for staff to explain.

The most useful preventive controls happen before a dispute is filed:

• use a recognizable descriptor;
• provide a receipt promptly;
• show cancellation/no-show terms before authorization;
• preserve evidence of the patient’s acceptance;
• send appointment confirmation;
• keep a check-in or attendance record;
• document transaction authorization;
• retain the appropriate record that the encounter occurred;
• document refunds and credits;
• keep patient billing communications;
• reconcile every payment to the patient ledger.

A remote transaction should not be defended by dumping the patient’s medical record into a chargeback package.

Dispute evidence should be limited to material that is appropriate for the specific request and handled under applicable privacy requirements, processor/acquirer instructions, internal policy, and compliance review. 

The practice may be able to establish authorization, attendance, transaction history, policy disclosure, or refund status without disclosing detailed diagnoses or treatment notes.

Where a processor or acquirer requests evidence that could include PHI, the request should be evaluated rather than automatically fulfilled by billing staff.

A strong internal dispute packet can also separate two questions: Was the card transaction authorized? and Was the underlying patient balance valid? Those issues sometimes overlap, but they are not identical.

Reconciling Telehealth Payments With the Patient Ledger

A payment is not finished when the gateway says “approved.” It is finished operationally when the transaction is correctly reflected in the patient’s account and reconciled to the encounter.

A clean sequence looks like this:

Appointment ID → Encounter → Payment authorization/consent → Transaction ID → Claim, if applicable → Payer adjudication → Final patient balance → Additional payment, credit, or refund → Closed ledger

That structure makes it easier to detect several common problems.

A patient may pay a copay before the visit and later receive a statement that accidentally ignores it. A refund may be sent through the processor but never posted to the patient account. A failed transaction may remain marked “paid” in the practice-management system. An insurance adjustment may change the balance after an initial patient payment.

Daily or weekly reconciliation checklist

• Match settled transactions to the correct patient account and encounter.
• Identify successful transactions that did not post to the ledger.
• Identify ledger payments without corresponding processor transactions.
• Confirm failed and declined payments are not marked as paid.
• Review voids separately from completed refunds.
• Match refunds to the original transaction and patient credit.
• Review partial payments.
• Investigate duplicate transactions.
• Post insurance adjustments before calculating the next patient amount.
• Review unapplied cash or unmatched credits.
• Confirm post-adjudication balance requests account for earlier pre-service payments.
• Close encounters only when the financial status is explainable.

For larger groups, reconciliation should also identify which system is authoritative when the processor, portal, EHR, and accounting system show different statuses.

Common Telehealth Patient Payment Collection Mistakes

1. Charging an estimate as though it were final

A deductible or coinsurance estimate is useful for financial conversations, but it may change after adjudication. Calling it a final balance can lead to overcollection and unnecessary refund work.

2. Keeping card details manually

Card numbers copied into spreadsheets, ordinary notes, email, or general-purpose files bypass the controls that a dedicated payment environment is designed to provide.

3. Storing CVV

PCI DSS prohibits retaining card verification codes after authorization. A stored credential workflow should not depend on keeping the CVV for the next transaction.

4. Treating card-on-file permission as unlimited

Authorization for one transaction or defined class of balances should not silently become permission to initiate any future charge under any circumstance.

5. Hiding telehealth no-show payment policy terms

If a patient only discovers the cancellation fee after it is charged, the practice creates an avoidable dispute and patient-experience problem.

6. Using an unfamiliar card descriptor

Patients can dispute legitimate charges because the statement name bears no obvious relationship to the practice they visited.

7. Automatically charging when the clinician cancels

A patient cancellation policy should not be applied blindly when the practice or clinician caused the appointment not to occur.

8. Sending excessive PHI into the payment environment

A processor does not need detailed clinical notes simply to settle an ordinary card transaction. Keep clinical information in the appropriate clinical system unless a legitimate function requires otherwise.

9. Confusing permission with processor authorization

A signed or clicked card-on-file agreement does not mean a particular charge has been successfully authorized by the card issuer. Conversely, a processor approval does not answer whether the practice was entitled to initiate that charge under its patient agreement.

10. Failing to reconcile a refund

If the gateway shows a $75 refund but the EHR still shows the $75 payment as applied, the patient ledger is wrong even though funds were returned.

11. Collecting a second balance without crediting the first payment

Post-adjudication collection must account for copays, deposits, self-pay prepayments, and other amounts already posted to the encounter.

12. Failing to send receipts

Receipts give patients a reference for what was charged and give staff a shared transaction record when questions arise.

A Telehealth Payment Policy Checklist for Practice Managers

Before implementation

• Map every system that touches patient payment information.
• Identify which vendor receives raw card data.
• Confirm how tokenization and stored credentials actually work.
• Determine PCI DSS responsibilities for the real architecture.
• Review whether vendors performing PHI-related functions require business-associate analysis.
• Separate HIPAA, PCI DSS, card-network, payer, and merchant-agreement requirements.
• Have financial policies reviewed for relevant state law and payer/program requirements.
• Decide which system is authoritative for the patient balance.

At scheduling

• Present relevant self-pay and cancellation terms.
• Identify whether the expected amount is fixed, estimated, or unknown.
• Offer an appropriate secure payment-method capture process.
• Record financial-policy acceptance.
• Avoid collecting unnecessary clinical information in payment fields.

At virtual check-in

• Confirm appointment attendance.
• Update payer information where applicable.
• Recheck eligibility according to practice procedure.
• Confirm the payment method.
• Display the amount and label it accurately.
• Resolve questions before initiating an avoidable charge.

During payment

• Use the correct transaction type for the workflow.
• Keep the transaction connected to the encounter reference.
• Do not store CVV after authorization.
• Avoid exposing raw card data unnecessarily.
• Record transaction status and ID.
• Send a recognizable receipt.

After the encounter

• Confirm whether the service occurred.
• Address cancellations and connection failures.
• Post the patient payment correctly.
• Submit any applicable claim through the normal billing workflow.
• Document credits, voids, or refunds.

After claim adjudication

• Post payer payment and contractual adjustments.
• Confirm final patient responsibility.
• Apply all prior patient payments.
• Issue a credit or refund for overpayment where appropriate.
• Request only the remaining balance.

During refunds or disputes

• Verify the underlying encounter.
• Review the financial policy version accepted by the patient.
• Identify whether the disputed amount was a service payment or missed-appointment fee.
• Check prior refunds and credits.
• Limit sensitive evidence to what is appropriate.
• Reconcile the final outcome back to the patient ledger.

Frequently Asked Questions

Should a practice collect payment before a telehealth visit?

It depends on what is known. A fixed self-pay charge or sufficiently confirmed copay may be appropriate for pre-service collection under the practice’s applicable policies and agreements. When deductible or coinsurance responsibility is uncertain, capturing an authorized payment method before the visit may be preferable to charging a speculative amount.

Can we keep a patient’s card on file for future telehealth visits?

A practice can use a properly designed stored-credential workflow when permitted and appropriately authorized. Modern setups frequently use processor or gateway tokenization rather than retaining the raw card number in ordinary staff-accessible systems. 

The practice should verify its architecture, patient authorization, merchant agreement, network requirements, and applicable law.

Can we automatically charge a copay before the video visit?

A practice may collect a known copay before a visit when its workflow, patient authorization, payer obligations, and applicable requirements support doing so. Staff should avoid assuming that every eligibility response is immutable or that the same rule applies to every payer.

What happens if the deductible amount is unknown?

Treat it as uncertainty, not as a final bill. The practice can communicate an estimate where appropriate, retain an authorized payment credential if permitted, submit the claim, and reconcile the eventual payer-determined patient responsibility before collecting the remaining balance.

Are telehealth card payments considered card-not-present?

Many are. When the patient’s card is not physically read at the practice and the credential is instead submitted remotely through a portal, website, telephone process, or stored credential, the transaction generally follows a card-not-present payment pathway.

Can a practice store a patient’s CVV?

No—not after authorization. PCI DSS treats card verification codes as sensitive authentication data and prohibits retaining them after authorization, including for future card-on-file transactions.

What should happen if the clinician cancels?

The practice should not simply apply a patient no-show rule to a clinician cancellation. Review any advance payment under the disclosed policy and determine whether it should be voided, refunded, credited to an agreed rescheduled visit, or otherwise adjusted.

Should a patient get a refund if the video connection fails?

Not every connection failure has the same financial result. Staff should determine how much care was actually delivered, who caused the failure, whether the appointment was completed or rescheduled, whether insurance was billed, and what the disclosed policy provides before deciding between a refund, void, credit, or retained service payment.

Can a telehealth practice charge a no-show fee?

Possibly, but there is no universal rule or fee amount applicable to every practice. State law, payer and program requirements, patient agreements, and the practice’s own policy can affect whether and how a no-show fee may be charged.

What should appear on a telehealth payment receipt?

A useful receipt normally identifies the recognizable practice or billing entity, transaction date, amount, receipt or transaction reference, a general service or payment description, and patient-facing billing contact information. Avoid unnecessary diagnoses or other sensitive clinical details.

What should appear on the credit-card statement descriptor?

Use a billing identity that the patient is likely to recognize, within the format supported by the processor and network. An unfamiliar corporate name can make a valid telehealth charge appear fraudulent to the patient.

Does the payment processor need the patient’s diagnosis?

Ordinary card processing generally does not require the processor to receive detailed diagnoses or clinical notes simply to authorize and settle a payment. Practices should determine what information is legitimately required for the particular vendor function and apply appropriate privacy controls.

How should a payment be linked to the medical encounter?

Maintain an internal relationship among the appointment or encounter ID, transaction ID, amount, timestamp, payment status, and patient ledger. The payment system can use a minimal reference where needed while detailed clinical information remains in the EHR or other appropriate system.

When should a patient receive a balance bill after insurance?

The practice should first post payer adjudication, adjustments, and any patient payments already received. The balance request should reflect the remaining patient responsibility rather than simply reproducing the amount assigned by the payer without considering prior payments.

How can a practice reduce disputes over virtual-visit charges?

Use recognizable descriptors, disclose financial and cancellation terms in advance, document authorization, send receipts, preserve appointment and transaction records, respond consistently to cancellations and technical failures, and reconcile refunds and credits promptly. Avoid sending unnecessary PHI merely to strengthen a dispute response.

Conclusion

Effective telehealth patient payment collection is less about charging earlier and more about charging at the right point in the financial workflow.

Capture payment information early when doing so supports the patient experience and collection process, but distinguish securely tokenizing a credential from permission to make future charges. 

Collect a known copay or fixed self-pay amount when appropriate, while clearly identifying deductible and coinsurance figures as estimates when the final responsibility has not been established.

Remote card payments also require attention to card-not-present controls, PCI DSS obligations, recognizable descriptors, receipts, and documented card-on-file authorization. At the same time, payment systems should receive only the information they need; diagnoses and free-text clinical notes generally belong in the appropriate healthcare system, not in ordinary payment fields.

Finally, close the loop. Every payment, authorization, void, credit, claim adjustment, additional balance, and refund should reconcile to the same encounter. 

That combination—early capture, accurate timing, restrained data sharing, clear patient communication, and disciplined reconciliation—creates a telehealth payment process that is easier for staff to operate and easier for patients to understand.