Many healthcare practices that take card payments assume their payment processor sits outside HIPAA. Often that's true. But it isn't true because of who the processor is. It's true, or not, because of what you've sent it.
HIPAA has a specific carve-out for payments. Section 1179 of the Social Security Act, enacted with HIPAA, says HIPAA's administrative simplification rules don't apply to financial institutions, or to entities acting for them, to the extent they are authorizing, processing, clearing, settling, billing, transferring, reconciling, or collecting payments for health care. Whether it covers a given processor and a given set of data is a question for your counsel.
The carve-out covers the payment. It doesn't obviously cover everything else a modern processor can hold, like product catalogs, itemized invoices, customer notes, metadata, and dispute files. Once your processor holds the reason for a charge and not just the charge, you're betting the exemption stretches that far, and that's a bet to confirm with counsel, not assume.
So the useful question isn't “is my processor HIPAA compliant?” It's “what have we put in it?” You can answer that in about five minutes with your processor's dashboard open.
- Minute 1Catalog
products / prices - Minute 2Invoice + receipt
invoices / emails - Minute 3Payment fields
description / metadata - Minute 4Customer + descriptor
customers / statement - Minute 5Disputes
evidence / support
What counts as a hit
You're looking for anything that tells a reader why someone paid. The amount and the card are what the payment exemption is meant to cover. The problem is healthcare meaning attached to the payment, such as a medication, a condition, a procedure, a dose, a visit type, a treatment phase, or a program name.
If someone with access to your payments dashboard could guess what a patient is being treated for, that's a hit.
Minute 1: Your product catalog
Open the products or prices list in your processor. If you bill memberships, subscriptions, or packages, this is where most practices find their first hit. Count it if you see:
- Product or price names that name a medication, a dose, or a treatment, like “Weight-loss program, Month 3” or “Fertility monitoring package”
- Phase or tier names that imply where a patient is in their care
- Product descriptions or images that explain the service
Generic names like “Membership” or “Monthly plan” are fine on their own. The test is whether the name carries clinical meaning.
Minute 2: A recent invoice and its receipt
Pick a recent charge and open the invoice and the receipt your processor sent the patient. Count it if you see:
- Line items that describe the service rendered
- Memo, footer, or note fields with visit or treatment detail
- Processor-sent receipt emails that repeat the product name from Minute 1
A processor-generated receipt is processor-held data, and it lands in an inbox that may be shared with a partner or a parent.
Minute 3: The fields behind a single payment
This is the check your engineers know about and your operations team may not. Open one payment and look at its description and metadata, the key/value pairs your integrations attach to each charge. Count it if you see:
- A description populated with a plan name, appointment, or provider specialty
- Metadata keys like plan_name, visit_type, program, or diagnosis_code with readable values
- Checkout or return URLs that include a plan or program in the path
$249.00 USD
- description
- Month 3, weight-loss programHit
- metadata.program
- weight-loss-phase-2Hit
- metadata.specialty
- endocrinologyHit
- statement_descriptor
- RIVERSIDE WTLOSS MO3Hit
$249.00 USD
- description
- Invoice payment
- metadata.ct_invoice_ref
- ctinv_8f3k2p9x
- metadata.ct_tenant_ref
- ctten_51x9wd
| Item | Amount |
|---|---|
| Weight-loss programMonth 3 · monthly membership | $199.00 |
| Provider check-inIncluded visit, Sep 2026 | $50.00 |
| Total | $249.00 |
Your patient sees this after signing in to your patient portal, which reads it from CopperTab.
Minute 4: Customer records and your statement descriptor
Open a couple of customer records, then check the statement descriptor, the short text that shows up on a patient's bank or card statement. Count it if you see:
- Customer notes, descriptions, or custom fields that mention treatment, referrals, or clinical history
- Context added to a customer's name or email label to tell patients apart
- A statement descriptor that names a treatment or program instead of your business
The descriptor deserves a second look. It ends up on statements that other people in a household may read. And if your business name itself signals a specialty, ask counsel whether a more neutral descriptor makes sense.
| Date | Description | Amount |
|---|---|---|
| 09/02 | NEIGHBORHOOD MARKET | 82.14 |
| 09/05 | 249.00 | |
| 09/09 | CITY WATER UTILITY | 61.30 |
| 09/12 | CORNER HARDWARE | 23.87 |
Minute 5: Disputes and support tickets
This is the easiest one to forget. When a patient disputes a charge, the natural instinct is to prove the service happened, and the most convincing proof is clinical: visit notes, intake forms, a signed treatment consent. Count it if you see:
- Dispute evidence uploads that include chart notes, treatment plans, or clinically itemized invoices
- Support conversations with your processor that discuss a specific patient's care
Disputes are about whether a payment was authorized and delivered as agreed. Work out with counsel what a neutral evidence package looks like before the next one arrives, not while the response clock is running.
Scoring it
Why it keeps coming back
Hits tend to come back. Cleanup fixes the data; it doesn't fix the cause. Open text fields like product names, descriptions, and itemized invoices are the right design for commerce in general. Healthcare billing just has to be more careful about what goes in them, and every new plan, new hire, or integration change is another chance to type something meaningful into one.
The fixes that last are structural, not reminders:
- Keep the processor uninformed on purpose. Use generic names and opaque references everywhere, and enforce it in code with an allowlist of the fields your integration may send, rather than a list of things people should remember not to type.
- Put the billing context under a BAA. If your processor offers a BAA, find out exactly which of its products it covers. If it doesn't, the clinical side of billing needs to live somewhere that does.
- Separate the layers. Keep plans, invoices, and line items in a billing system covered by a BAA, and send the processor only an amount, a currency, a payment token, and an opaque reference.
The third option is what CopperTab is built for. Plans, invoices, and patient billing records live in CopperTab, which is designed to act as your business associate, and Stripe receives a neutral charge: an amount, a currency, a payment method token, and opaque references. Our Stripe calls are limited by an allowlist of payment fields, so clinical detail is designed to stay out. Your patients still get a fully itemized invoice. It lives in CopperTab, and your patient portal shows it to them after they sign in. If you want the mechanics, our walkthrough of what happens when CopperTab sends a charge to Stripe covers it field by field.
Whatever you use, run the test. It's easier to find this yourself, on your own schedule.