TL;DR: HIPAA does not regulate the card transaction itself. Federal law (§1179, codified at 42 U.S.C. 1320d-8) exempts payment processing from HIPAA, and a card number used only to take payment is not protected health information. You need a Business Associate Agreement only when your processor's system also touches patient health information. Get that distinction right and you can stay compliant without paying a "healthcare" markup.
Most articles about healthcare payment processing tell you to buy a "HIPAA-compliant processor" and sign a Business Associate Agreement, then stop. That advice is incomplete, and the gap costs practices money. Some overpay for a compliance package they may not need. Others skip a Business Associate Agreement they absolutely do need, then find out during a breach investigation.
The truth sits on a line most vendors never draw: HIPAA governs health information, not card numbers. Get the line right and the compliance work gets smaller and cheaper.
This post draws that line using the actual federal statute and regulations, not a vendor's summary of them. Every regulatory claim below links to the primary source.
What does HIPAA actually require of payment processing?
Less than most people assume. HIPAA (the Health Insurance Portability and Accountability Act, US federal law) protects individually identifiable health information. It does not govern the mechanics of moving money.
Congress wrote this exemption directly into the statute. Section 1179 of the Social Security Act, codified at 42 U.S.C. §1320d-8, states that HIPAA "shall not apply" to an entity engaged in "authorizing, processing, clearing, settling, billing, transferring, reconciling, or collecting" payments for health care. When a bank or processor runs the card transaction, that activity is outside HIPAA by law.
The Privacy Rule reinforces this from the other side. Under 45 CFR 164.506(c), a covered entity may use and disclose protected health information for payment activities without the patient's authorization. Billing a patient and collecting the payment is a permitted use. You do not need a signed release to charge a card for services rendered.
So the baseline requirement is narrower than the marketing implies. HIPAA does not demand that the payment rail itself be "HIPAA-certified." It cares about what happens to health information, which is a different question.
Is a credit card number PHI?
On its own, no. This is the distinction that changes everything downstream.
Protected health information is individually identifiable information about a person's health, care, or payment for care, held by a covered entity or its business associate. A 16-digit card number, an expiration date, and a dollar amount are payment card data. They are governed by the PCI Data Security Standard, not HIPAA.
The card number becomes entangled with PHI only when it is stored or transmitted alongside health context. "Card ending 4242 paid $180" is payment data. "Jane Doe paid $180 for a diabetes follow-up with Dr. Lee on June 3" is protected health information, because it links an identifiable person to their care.
That single sentence is the whole compliance question for most practices. If your payment system only ever sees the card and the amount, HIPAA has little to say about it. If your system stores patient names next to services, diagnoses, appointment dates, or itemized treatment on statements and portals, PHI is now in the payment flow, and HIPAA applies to whoever holds it.
Does your payment processor need a HIPAA Business Associate Agreement (BAA)?
It depends on one thing: whether the processor's system touches PHI, not just card data.
A business associate is a vendor that creates, receives, maintains, or transmits protected health information on a covered entity's behalf. When a vendor meets that definition, 45 CFR 164.502(e)(1) requires a written Business Associate Agreement before any PHI is disclosed to them. The agreement documents "satisfactory assurances" that the vendor will safeguard the information.
Here is how the two rules interact:
- Pure payment processing. A processor that only authorizes and settles the card transaction is covered by the §1179 exemption and is generally not a business associate. A BAA is not strictly required for that narrow activity.
- Processing that touches PHI. A processor whose platform stores patient identifiers tied to care, displays itemized medical statements, hosts a patient payment portal, or keeps records connecting a person to appointment dates and providers is handling PHI. That makes it a business associate, and a BAA is required.
In practice, most healthcare payment setups fall into the second category. Patient statements carry names and services. Portals show balances tied to visits. Recurring payment plans reference the treatment being paid off. The moment any of that lives in the payment vendor's system, you need a BAA.
The practical rule we give practices: if a vendor's system could reasonably see PHI, get the BAA. It is inexpensive, most processors that serve healthcare will sign one, and it removes the guesswork. Signing an unnecessary BAA costs you nothing. Skipping a required one is a standalone HIPAA violation, whether or not a breach ever happens.
How is PCI DSS different from HIPAA, and do you need both?
Yes, you need both, because they protect different data.
The PCI Data Security Standard is set by the PCI Security Standards Council, the body founded by the major card brands. It governs how card data is stored, processed, and transmitted. It is a contractual standard enforced through your processor and the card networks, not a government law.
The current version is PCI DSS v4.0.1, published June 11, 2024. Version 4.0 was retired on December 31, 2024, and the future-dated requirements first introduced in v4.0 became effective on March 31, 2025. Every business that accepts cards is expected to comply, healthcare or not.
The split is clean:
- PCI DSS protects the card data. It applies to every merchant that takes cards.
- HIPAA protects the health information. It applies to covered entities and their business associates.
A dental office taking a copay is subject to both at once. PCI DSS governs the card; HIPAA governs the patient record the card is attached to. Compliance with one does not satisfy the other. A processor can be fully PCI compliant and still owe you a BAA because its system displays patient names next to services.
The good news for cost: PCI compliance is standard infrastructure that every legitimate processor already provides. You should never pay a premium as if it were a special healthcare feature.
What does a HIPAA-compliant payment setup actually look like for a small practice?
It has four parts, and none of them is exotic.
1. Tokenization and encryption. Card data should be tokenized at capture, so the actual number never lands in your systems. This shrinks your PCI scope and keeps card data out of any place PHI lives. Point-to-point encryption on terminals does the same for in-person payments.
2. A BAA with any vendor that touches PHI. Your practice management system, your patient portal, and your payment vendor each need a Business Associate Agreement if their platform handles PHI, per 45 CFR 164.502(e)(1). Keep the signed agreements on file.
3. Minimum-necessary PHI in the payment flow. Do not send more health information into the payment system than billing requires. A statement can reference an invoice number instead of a diagnosis. Less PHI in the flow means less exposure and a smaller BAA footprint.
4. Standard PCI DSS controls. Access controls, current software, and the self-assessment questionnaire (SAQ) appropriate to how you accept cards. Most small practices using a tokenized, hosted setup qualify for the shortest SAQ.
Put together, this is a normal modern payment setup with one addition: a BAA wherever PHI is in play. It does not require a boutique "healthcare processor" charging boutique rates.
How much does getting it wrong actually cost?
Enough to make the compliance work worth doing correctly the first time.
Healthcare has been the most expensive industry for data breaches for well over a decade. The average healthcare breach cost $7.42 million in 2025, down from $9.77 million the year before but still the highest of any sector (IBM Cost of a Data Breach Report 2025). Those numbers are driven by large organizations, but the per-record exposure and the enforcement framework apply to a five-person practice too.
The regulatory penalties are separate from breach costs. HIPAA civil monetary penalties are tiered by culpability and adjusted annually for inflation. As adjusted effective January 28, 2026, they run from $145 per violation at the lowest tier up to a $2,190,294 annual cap per violation category (US Department of Health and Human Services, Federal Register civil monetary penalty adjustment). Operating without a required BAA is itself a violation, independent of whether any data is ever exposed.
Against that backdrop, a BAA you did not strictly need is the cheapest insurance in the building.
How do you keep healthcare payment processing affordable?
By refusing to pay a vertical markup for standard capabilities, and by pricing the parts that actually vary.
Three levers matter most for a practice:
Interchange-plus pricing. Ask for interchange-plus, which exposes the true card-network cost and adds a fixed, visible processor markup. Flat-rate and tiered pricing hide the markup, and for practices with high average tickets that gap is real money. See our breakdown of interchange-plus pricing for how to read it.
No "healthcare processor" premium. Tokenization, encryption, and PCI compliance are baseline features, not healthcare add-ons. A BAA is a signed document, not a product tier. If a processor quotes a higher rate because you are a medical practice, that is a sales position, not a cost.
HSA and FSA card acceptance and payment plans. Practices collect more when patients can pay with health-spending cards and split larger balances over time. Recurring billing for treatment plans reduces the accounts-receivable problem that quietly costs practices more than processing fees ever do.
Low-risk medical and dental practices also board quickly. Standard underwriting for a low-risk merchant typically runs 24 to 48 hours, so there is no reason to accept a slow, expensive setup as the price of compliance.
What should you ask a processor before signing?
Five questions separate a straight answer from a sales pitch:
- Will you sign a BAA? Any processor whose system could touch PHI should say yes without friction. Hesitation is a signal.
- Is card data tokenized at capture? You want the real card number to never enter your systems.
- Is this interchange-plus pricing, and can I see the markup? A clear yes with a visible number is the answer you want.
- What SAQ will my practice complete? A processor who serves healthcare knows this immediately.
- Are there any fees specific to healthcare or "compliance"? There should not be. Compliance is how the service is built, not an upcharge.
If the answers are clean, the setup is compliant and reasonably priced. If they are vague, keep looking.
ClickWerxs boards low-risk medical and dental practices on merchant accounts with tokenized card capture, interchange-plus pricing, and a Business Associate Agreement wherever PHI is in play. See how we handle healthcare payment processing, or get a quote and compare it line by line against what you pay now.
Frequently Asked Questions
Is Stripe or Square HIPAA compliant for a medical practice?
Neither positions itself as a HIPAA business associate for standard accounts, and their standard terms generally do not include a BAA. That can be fine if your setup keeps PHI out of their systems, but if patient identifiers tied to care flow through the payment platform, you need a vendor that will sign a BAA. Confirm in writing before assuming any processor's default account covers you.
Do I need a BAA if I only take card payments at the front desk in person?
If the terminal captures only the card and amount and nothing links the payment to health information inside the processor's system, the §1179 payment-processing exemption generally covers it and no BAA is strictly required. In practice, if your point-of-sale or reporting ties the transaction back to a patient chart or itemized service, PHI is involved and a BAA is the safe call.
Does PCI compliance make me HIPAA compliant?
No. PCI DSS protects card data and HIPAA protects health information. They are separate obligations enforced by different bodies. A processor can be fully PCI compliant and still owe you a Business Associate Agreement because its platform displays patient names alongside services.
Can I charge a patient's card without their written authorization under HIPAA?
Yes. Under 45 CFR 164.506(c), using and disclosing protected health information for payment is a permitted activity that does not require patient authorization. You still need the cardholder's consent to charge the card as a matter of payment-network rules, but HIPAA itself does not require a separate release to bill for care provided.
Who is liable if my payment vendor causes a breach of patient data?
Both the vendor and your practice can face exposure. Under HIPAA, a covered entity and its business associate each carry obligations, which is exactly why the BAA exists: it allocates responsibility and documents the safeguards. Without a required BAA in place, your practice absorbs more of the risk and the missing agreement is itself a violation.
ClickWerxs facilitates merchant account applications and provides ongoing account management as an authorized representative of our banking and processing partners. Approval, rates, and terms are determined by the issuing processor and acquiring bank — ClickWerxs does not guarantee approval for any merchant account application. Processing rates and fee structures cited in this post reflect publicly available industry data and general ranges; your actual rate depends on your industry, volume, and card mix. This post is not legal or financial advice. For a custom quote, see clickwerxs.com/payments/get-a-quote.
This post reflects publicly available regulatory information as of the publication date. HIPAA and PCI DSS requirements vary by situation and change over time. This is not legal advice. Consult qualified legal counsel before making compliance decisions for your practice.
Kaleb Dickhaut Founder, ClickWerxs linkedin.com/in/kaleb-dickhaut
Kaleb built ClickWerxs from the ground up — from payment processing ISO to the Command Center platform to the AI SEO methodology the blog runs on. He has onboarded hundreds of small businesses onto payment and CRM systems.
Sources
- Processing rates, fee ranges and effective-rate figures in this post are industry-typical ranges compiled from published network schedules and from accounts reviewed in the ClickWerxs ISO portfolio. They are not quoted rates. Interchange itself is set by Visa and Mastercard on published schedules that change twice yearly; your actual cost depends on card mix, MCC, ticket size and volume.
- PCI DSS — the Payment Card Industry Data Security Standard is maintained by the PCI Security Standards Council; current version and transition dates are published in the council's document library rather than on a single rate page. pcisecuritystandards.org
- Card network monitoring thresholds — Visa's Acquirer Monitoring Program (VAMP) replaced the Visa Dispute Monitoring Program and Visa Fraud Monitoring Program effective 1 April 2025 and measures fraud reports and disputes combined; the merchant Excessive threshold is 1.50% above a floor of 1,500 combined events per month as of 1 April 2026. Mastercard's Excessive Chargeback Merchant tier is 100 chargebacks and 150 basis points. Visa distributes VAMP terms through acquirer bulletins rather than a public page; confirm current thresholds with your acquirer.
- ClickWerxs ISO portfolio, aggregate observation — patterns described from merchant accounts under ClickWerxs management. Anonymized and reported in aggregate; individual account terms vary. Operator data.
ClickWerxs facilitates merchant account applications and provides ongoing account management as an authorized representative of our banking and processing partners. Approval, rates, and terms are determined by the issuing processor and acquiring bank — ClickWerxs does not guarantee approval for any merchant account application. Processing rates and fee structures cited in this post reflect publicly available industry data and general ranges; your actual rate depends on your industry, volume, and card mix. This post is not legal or financial advice. For a custom quote, see clickwerxs.com/payments/get-a-quote.