For about a decade, the team behind CopperTab has been building software for healthcare companies. Fertility clinics, telehealth platforms, direct primary care practices, patient payment workflows: if it involved healthcare and software, we were probably in it. Echobind, the agency that built CopperTab, has been a Stripe Premier Partner for years. We know how good Stripe is. We've shipped a lot of systems that rely on it.
And again and again, we kept hitting the same wall.
One product name
A healthcare client wants to bill patients. They already have a Stripe account. They want to set up subscriptions for a membership program, or charge for a package, or run a GLP-1 protocol for a set monthly fee. So they go to create a product in Stripe, and they need to give it a name. They type something like “Semaglutide 0.5mg, Month 3 Maintenance” and hit save.
That name is now in Stripe.
That product name, which reveals a medication, a dose, and a treatment stage, just traveled to a system that isn't covered by a Business Associate Agreement. Stripe is a horizontal payment platform. It isn't designed to be a HIPAA-covered environment, and Stripe doesn't sign BAAs. So the moment you put a clinically meaningful descriptor into a line item, an invoice, a product name, or a metadata field, you may have sent protected health information to a platform that isn't in HIPAA scope for that data.
This is not a criticism of Stripe. Stripe is excellent infrastructure. The problem is architectural: you're using a horizontal tool for a vertical-specific job, and the gap shows up in the data you have to pass through it.
The workarounds never held
The clients we worked with knew the rules. They weren't being careless. But Stripe's interface wants product names, invoice descriptions, metadata, customer notes. When your product is healthcare, those fields are a minefield. So they improvised. Some used code names, like “Package A” or “Program 3,” and kept a separate spreadsheet mapping codes to the actual clinical program. Others tried to sanitize everything at the application layer before anything reached Stripe. A few just hoped nobody would ask.
billing_codes_v4_FINAL_real.xlsxLast edited 3 weeks ago| Row | Name in Stripe | What it actually is |
|---|---|---|
| 2 | Package A | Weight-loss program, months 1–3 |
| 3 | Package B | Weight-loss program, maintenance |
| 4 | Program 3 | Fertility monitoring cycle |
| 5 | Program 4 | MissingNever added to the sheet |
None of those are real solutions. The spreadsheet adds operational overhead and breaks the moment someone is out sick. Application-layer sanitization is fragile: one missed field, one new engineer who doesn't know the rule, and something slips through. And hoping for the best is not a compliance posture.
The answer was always architectural
The right answer was always architectural: a layer that sits between your healthcare billing context and your payment processor, that holds the sensitive data under a BAA, and that sends Stripe only what Stripe needs: an amount, a currency, a payment method token, and opaque references.
That's what CopperTab is.
We built it because we got tired of building bespoke versions of it for individual clients. Every healthcare company that touched Stripe needed some version of this layer. It was always custom, always expensive, and always a little different from the last one. At some point you stop building the same thing from scratch and you build the product.
CopperTab runs on top of your existing Stripe account using Stripe Connect. You keep your Stripe account. You keep your normal Stripe rates. CopperTab is the HIPAA-compliant layer on top that handles everything Stripe shouldn't touch: the patient billing context, the clinical plan names, the invoice line items, the subscription logic. All of that lives in CopperTab's encrypted environment. CopperTab-authored Stripe payloads carry only the data needed for a neutral charge: an amount, a currency, a payment method reference, and opaque CopperTab references. Your statement descriptor comes from your Stripe account settings, not from CopperTab, so make sure it names your practice rather than a program. CopperTab is designed so that no diagnosis, medication, or treatment detail reaches Stripe.
Card details are entered by the payer directly into Stripe's hosted fields, which means raw card numbers pass from the payer's browser to Stripe without going through CopperTab's servers. (We walk through that flow field by field in what happens when CopperTab sends a charge to Stripe.) We're not trying to be a payment processor. We're trying to be the right layer between your billing context and the payment processor you already use.
A BAA on every plan
One more thing worth naming: BAA included on every plan. That's not an enterprise feature. It's not a checkbox you unlock at the top tier. It's part of the product for every customer, because compliance shouldn't be a pricing lever.
This is not a complicated origin story. We saw a real problem, we had the infrastructure expertise to solve it properly, and we built the thing. If you run a healthcare practice that takes patient payments, like a GLP-1 clinic, a med spa, a DPC practice, a fertility clinic, or a men's health program, and you're using Stripe or want to, CopperTab is built for exactly your situation.
We're glad it exists. We think you will be too.