What Is Dual Pricing and How Is It Different from Cash Discount?
Fri Oct 16 2026
Most practice managers assume that accepting a credit card at the front desk is automatically a HIPAA matter, simply because it happens inside a medical office. The reality is more specific than that, and getting it wrong in either direction creates a real problem: assuming too little compliance leaves a practice exposed, while assuming every payment touchpoint is automatically HIPAA-governed can lead to over-engineering a system that never needed that level of scrutiny in the first place.
Quick Answer: HIPAA-compliant payment processing means the processor has signed a Business Associate Agreement, maintains PCI DSS compliance for cardholder data, and the practice keeps protected health information, patient names tied to diagnoses, treatment details, or billing codes, out of the payment transaction itself wherever possible. A card number alone is not protected health information; it falls under PCI DSS. HIPAA applies specifically when payment data can identify a patient and relate to their care, billing, or coverage. Banks and payment processors that are simply moving money are generally exempt from HIPAA obligations, which is why the compliance question depends on your specific setup rather than which processor's marketing page uses the word "HIPAA."
What Does "HIPAA-Compliant Payment Processing" Actually Mean?
This term gets used loosely, and the loose usage causes real confusion for practice managers trying to evaluate vendors. HIPAA compliance is not a certification a payment processor holds in the abstract, independent of how it is actually used.
The distinction that matters: PCI DSS governs the security of cardholder data, the card number, expiration date, and CVV. HIPAA governs protected health information, or PHI, which includes patient names, dates of service, diagnosis codes, and other details tied to a patient's care or billing when connected to payment data. A processor can be fully PCI DSS compliant and still create a HIPAA gap if PHI flows through it without the right agreements and safeguards in place.
According to guidance published in the HIPAA Journal, banks and payment processors are generally exempt from HIPAA when they are only moving money, meaning the transaction itself carries no PHI beyond what is necessary to process the charge. This is why the compliance question is really about your specific configuration, not a label a vendor applies to their product.
What Is the PHI-Touch Test?
This is a useful, practical way to think through whether a specific payment workflow actually falls under HIPAA scope, rather than assuming every payment touchpoint at a medical practice automatically does.
The test: A payment record that contains only a card token and a dollar amount stays outside HIPAA scope. The moment that same transaction record links to a patient name, a diagnosis code, a procedure description, or any other clinical detail, protected health information is present, regardless of whether the card number itself was tokenized.
Tokenization, the process of replacing a card number with a random, non-sensitive substitute value, removes cardholder data from your environment. It does not, by itself, keep PHI out of the transaction. A practice can tokenize every card on file and still have a HIPAA problem if the billing descriptor on that transaction includes a procedure name, or if a receipt sent to a patient references their diagnosis alongside the payment amount.
Where the distinction actually plays out in practice: A billing system and a payment system are conceptually separate layers. The billing system handles coding, claims submission, and patient statement generation. The payment solution handles the actual transaction, the charge and its authorization. When these two layers remain genuinely separate, the payment solution itself may never see PHI at all. When they merge, or when payment records are generated directly from billing data that includes clinical detail, the distinction collapses and PHI enters the payment workflow.
What Does a Practice Actually Need in Place?
Four elements, working together, determine whether a practice's payment setup is genuinely compliant.
1. A signed Business Associate Agreement (BAA). This is the legal contract between your practice and the payment processor that formally obligates the processor to safeguard any PHI it may handle and defines its specific responsibilities under HIPAA. Without a signed BAA, using a processor to handle any workflow that touches PHI creates real exposure, regardless of how secure the processor's technology actually is.
2. PCI DSS compliance for cardholder data. This is a separate standard from HIPAA, covering the security of card numbers specifically. Meeting PCI DSS does not automatically satisfy HIPAA requirements, and meeting HIPAA does not automatically satisfy PCI DSS. Both apply simultaneously whenever a healthcare payment workflow involves both cardholder data and PHI.
3. Tokenization and encryption. Card data should be tokenized so the actual card number never touches your systems or the processor's long-term storage. Data should be encrypted both in transit and at rest. These two measures together reduce both PCI scope and PHI exposure, since less sensitive data exists anywhere in your environment to protect in the first place.
4. Audit logs and role-based access controls. The HIPAA Security Rule requires audit controls for any system containing electronic PHI. Your payment processor should generate and retain access logs showing who accessed payment data, when, and what they did with it. This should be paired with role-based access, so a front-desk coordinator does not have the same level of access to payment and billing records as a billing manager.
What Mistakes Actually Put a Practice at Risk?
Using a processor that never signed a BAA. This is one of the most common gaps, particularly when a practice adopts a convenient payment tool, a text-to-pay app or a generic payment link generator, without confirming that vendor has actually agreed to HIPAA obligations in writing.
Including PHI in payment descriptors or receipts. A billing descriptor or receipt that references a procedure name, diagnosis, or treatment detail alongside the payment amount creates unnecessary PHI exposure in a document that may be sent, stored, or forwarded outside secure channels. Receipts should confirm what was paid, not what it was for in clinical terms.
Sending receipts through unsecured channels. A receipt sent by standard text message or unencrypted email that includes any patient-identifying clinical detail creates a real compliance gap, since those channels do not meet HIPAA's security requirements for transmitting PHI.
Treating PCI compliance as sufficient on its own. A practice that has achieved full PCI DSS certification has secured the cardholder data specifically, but that alone does not address the separate HIPAA obligations that apply the moment PHI enters the same workflow.
What Does HIPAA-Compliant Payment Processing Typically Cost, and How Does Approval Work?
Getting approved for a payment processing account intended to handle healthcare payments generally requires more documentation than a standard retail merchant account. Processors typically require a signed BAA, evidence of PCI DSS certification, often at the higher Level 1 tier, and documentation showing how your payment workflow integrates with your electronic health records or practice management system without exposing diagnostic or clinical data through that integration.
On pricing, many specialized healthcare payment providers use interchange-plus pricing rather than a flat-rate model, reflecting a general industry pattern toward more transparent, itemized pricing for practices that want to see exactly what they are being charged rather than a blended rate that obscures the underlying interchange cost.
How Does This Connect to Patient Payment Plans and Recurring Billing?
Many practices collect payment beyond a single point-of-sale transaction: recurring payment plans for larger treatment costs, card-on-file for copays across multiple visits, or membership-style billing for ongoing care programs. Tokenization becomes especially important in these recurring scenarios, since a stored card should exist only as a token, never as a raw card number sitting in a practice's own systems between billing cycles.
The same PHI-touch principle applies here: a recurring billing record that stores only a payment token, an amount, and a billing schedule stays outside HIPAA scope on the payment side. A recurring billing record that also stores treatment plan details or diagnosis codes alongside that payment schedule brings PHI into the payment workflow, and the safeguards above need to extend to that recurring system as well, not just the initial transaction.
Not Sure Whether Your Current Payment Setup Actually Meets HIPAA Requirements?
Rapid Payments reviews a practice's current payment workflow, confirms whether a proper BAA is in place, and identifies where PHI may be entering the payment process unnecessarily.
