A patient's phone buzzes at dinner with a receipt. It reads: "Payment of $180.00 to Lakeside Behavioral, for: Ketamine infusion, session 4." The phone is on the table. Her brother-in-law reads it upside down. Nothing was hacked. A staff member filled in a description field that a payment processor emailed to the customer, exactly as designed.
Is Stripe HIPAA compliant? No, and Stripe says so in its own contract. Stripe does not offer a B.A.A. (Business Associate Agreement) on any public page, and its Services Agreement defines "Protected Health Information" by reference to 45 CFR 160.103 and then states: "User must not provide Protected Health Information to Stripe as part of Third Party Data. User is liable for any disclosure of Protected Health Information to Stripe when User provides access to the Third Party Data." That does not make Stripe unusable for a practice. It makes Stripe a card processor that must never see P.H.I. (Protected Health Information), which is a constraint you can design around. This guide covers what Stripe's terms say, where PHI leaks into a payment flow, and the setup that keeps a Stripe account clean.
Is Stripe HIPAA Compliant: No BAA, a Contract Clause, and a Design Problem
Whether Stripe Signs a BAA
No. Stripe's legal pages, its Data Processing Agreement, its privacy center, and its security documentation do not mention a BAA or HIPAA at all. The only HIPAA language is the Services Agreement clause above, which appears in section 4.5 on data from third-party services, and the definition it relies on. Section 4.6 commits both parties to "commercially reasonable administrative, technical, and physical safeguards," which is a general data-protection promise, not the specific set of obligations 45 CFR 164.504(e)(2) requires of a business associate. Stripe is telling customers what it is: a payment company that does not want health information.
Whether a pure card transaction even creates a business associate relationship is a separate question. A business associate under 45 CFR 160.103 is a person who "creates, receives, maintains, or transmits protected health information" on a covered entity's behalf for a regulated function, and payment processing sits near a statutory carve-out for certain financial-institution activities that counsel can explain. The practical answer does not depend on winning that argument. If Stripe holds no PHI, the argument never has to be made.
The Stripe Plans and HIPAA Eligibility
None. Stripe's pricing tiers and products all sit under the same Services Agreement. There is no enterprise contract on a public page that adds a BAA, and the prohibition on PHI in third-party data is not tier-dependent.
Where PHI Leaks Into a Payment Flow
The card number is not the problem. Stripe's security documentation describes card data encrypted at rest, tokenized, and handled in an isolated environment. The problem is every free-text and descriptive field around the card, because those fields travel: to receipts, to statements, to exports, to support tickets, and to anyone Stripe shares data with under its own agreements. An identifier plus a service description equals PHI under 160.103, which covers information that "relates to ... the provision of health care to an individual" and identifies the person.
| Stripe touchpoint | PHI risk | Rule |
|---|---|---|
| Product and price names | "Suboxone follow-up" is a diagnosis | Neutral categories: "Office visit," "Session" |
| Payment description and metadata | Free text that appears on receipts and exports | Reference numbers only, never names plus conditions |
| Invoice line items and memos | Itemized clinical detail | Category and date; clinical detail stays in the EHR |
| Statement descriptor | The practice name on the patient's bank statement | Consider a neutral trade name for sensitive specialties |
| Customer records | Notes fields filled with clinical context | Name and email only, no notes |
| Receipt and invoice emails | Everything above, mailed to an address others may see | Minimal content; let patients opt in |
| Support tickets to Stripe | Staff paste a chart screenshot to explain a dispute | Never |
| Connected apps and the Stripe App Marketplace | Apps that read customer data | Each one is a vendor; no BAA, no PHI |
Why This Is Minimum Necessary, Not Just Stripe
Every row in that table is the same rule. 45 CFR 164.502(b)(1) requires a covered entity to "make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose." The purpose of a payment record is to prove that money changed hands for a service on a date. It does not need the diagnosis, and the diagnosis is exactly what turns an ordinary receipt into a disclosure. The minimum necessary guide covers the general rule; the payment flow is one of its cleanest applications.
The identifier side deserves the same care. Names, email addresses, and account numbers are all on the list of 18 HIPAA identifiers. A Stripe customer record with an email address and a product called "Anxiety counseling" is a PHI record sitting with a vendor whose contract forbids it.
How to Use Stripe in a Practice Without a Disclosure
- Write the field rules from the table above into the billing policy, and name the one person who may create products and prices in Stripe.
- Rebuild the product catalog with neutral names. Delete or archive anything descriptive.
- Purge metadata and descriptions. Search existing payments for clinical terms and patient details, then document the cleanup as a security incident review under 45 CFR 164.308(a)(6).
- Put the PHI-bearing front end somewhere covered. Intake forms, appointment details, and clinical notes belong in the EHR or a form tool that signs a BAA. Only the payment step touches Stripe.
- Review receipts and invoices as a patient would. Send yourself one. Anything on it that a stranger should not know comes off.
- Restrict Stripe dashboard access. Unique logins under 45 CFR 164.312(a)(2)(i), two-step verification, and removal at termination.
- Vet connected apps. Reporting tools, bookkeeping syncs, and CRM connectors that pull customer data are vendors with their own terms.
- Keep the bookkeeping clean too. Stripe exports flow into accounting software, and the QuickBooks analysis explains why clinical detail should never arrive there.
- Add Stripe to the risk analysis as a system that must hold no ePHI, with the field rules as the control.
- Train the front desk. The description field is filled in by a person. The person is the safeguard.
Common Stripe HIPAA Mistakes
Descriptive product names. The most common one, and the one that ends up on receipts.
Using Stripe Invoices as a superbill. A superbill needs codes and diagnoses. It belongs in the practice management system, not in an emailed Stripe invoice.
Pasting patient context into a dispute response. Chargeback evidence should prove a service was purchased, not what the service treated.
Assuming "Stripe is secure" settles it. Stripe's security is about card data. HIPAA is about the sentence typed next to it.
Alternatives for Practice Payments
| Option | BAA | Notes |
|---|---|---|
| Stripe | No; contract bars PHI in third-party data | Usable as a PHI-free card processor with strict field rules |
| Square | Published BAA covering Appointments, Invoices, and HIPAA-enabled features | Buyer-facing services excluded; still needs neutral service names |
| EHR or practice-management payments | Usually inside the EHR vendor's BAA | Keeps the clinical and payment records in one covered place |
| QuickBooks Payments | No | See the QuickBooks analysis linked above |
Stripe is a fine choice for the one thing it does. The practice's job is to make sure that one thing is all it ever sees: a card, an amount, a date, and a description that would bore a stranger. Everything else stays in systems that signed a BAA, and the receipt on the dinner table says nothing at all.
---
FAQ
Does Stripe sign a HIPAA Business Associate Agreement?
No. Stripe's public legal pages offer no BAA, and the Stripe Services Agreement states that users must not provide Protected Health Information to Stripe as part of third-party data and are liable for any such disclosure.
Can a medical practice use Stripe at all?
Yes, as a card processor that holds no PHI. That requires neutral product names, no clinical detail in descriptions, metadata, invoices, or memos, minimal receipts, and no patient context in support or dispute communications.
Is a payment receipt PHI?
It can be. A receipt that pairs a patient's name or email with a service description that reveals a condition or treatment is individually identifiable health information under 45 CFR 160.103. A receipt with a neutral category and a date generally is not.
Is there a Stripe plan or enterprise contract that includes a BAA?
None on any public Stripe page. Every product and pricing tier sits under the same Services Agreement, which contains the prohibition on providing PHI.
What should hold the clinical side of the transaction?
The EHR or practice-management system, or a form tool that signs a BAA. Stripe should receive only the payment step, and the two systems should share a reference number, not a diagnosis.
Conclusion
Taking payments without leaking patient information is a design problem, and it is solved with a short list of field rules. One Guy Consulting's Full-Scope plan includes vendor and BAA management, the policy templates, and consulting time to review every payment, receipt, and invoice touchpoint in your practice. Start with a free 30-minute compliance review. No obligation, no pressure.
Sources
- Stripe Services Agreement (section 4.5 Third Party Data, section 4.6 Controls, definition of Protected Health Information)
- Stripe: Security at Stripe (documentation)
- Stripe Data Processing Agreement
- 45 CFR 160.103 (definitions)
- 45 CFR 164.502 (uses and disclosures; minimum necessary at (b))
- 45 CFR 164.504 (business associate contract requirements at (e))
- Square: HIPAA Business Associate Agreement (for the comparison table)
Related Reading