What actually happens when CopperTab sends a charge to Stripe

If you run a healthcare practice and you're evaluating billing software, you've probably heard some version of “we keep your PHI safe.” That's a claim, not an explanation. This post is the explanation. We're going to walk through exactly what happens, step by step, when CopperTab processes a patient payment: what data we hold, what we send to Stripe, and why that separation is what makes this HIPAA-compliant by design rather than by policy.

This is written for a practice owner or a CFO who is smart but not necessarily a software engineer. There's a small amount of technical vocabulary here, but nothing that should slow you down.

The three-node model

Every CopperTab charge moves through three distinct nodes. Understanding what each node knows is the whole ballgame.

Node 1: the patient billing context. The patient's plan, diagnosis, clinical notes, medication, treatment history: whatever connects to why they're being charged. This information may live in your EHR, your intake forms, or CopperTab's dashboard. It is PHI.

Node 2: CopperTab's vault. All of that billing context is encrypted and stored here, under a Business Associate Agreement. When you set up a billing plan in CopperTab, you give it a real name, like “Semaglutide maintenance plan, 0.5mg” or “IVF monitoring cycle, Phase 2,” or whatever accurately describes the program. That name, and everything connected to it, lives in the vault. CopperTab is designed not to send it to Stripe.

Node 3: Stripe. Where the actual card charge happens. Stripe is excellent at this. But Stripe is a horizontal payment platform; it is not designed to operate as a HIPAA-covered environment for your clinical billing data. So CopperTab is designed to send Stripe only what Stripe genuinely needs to execute a payment. Nothing clinical.

What CopperTab holds, under BAA

Inside CopperTab's encrypted vault, covered by your BAA, you will find:

• Patient billing records, including names and contact information as needed for billing purposes
• Plan names and program details: the real clinical descriptions you actually use
• Diagnosis and clinical context associated with a billing event
• Subscription logic: billing intervals, program phases, price changes over time
• Invoice line items with accurate descriptions of services rendered
• Payment history linked to specific clinical programs
• Audit logs of every billing action

This is the record of what you charged and why. CopperTab holds it, encrypts it at rest and in transit, and covers it under your BAA.

What Stripe sees

Here is what CopperTab sends to Stripe when a charge is initiated:

• The amount and currency
• A payment method token: a non-sensitive identifier that Stripe issued previously when the patient's card was entered
• An opaque CopperTab reference, like ctinv_8f3k2p9x: a string of random characters that means nothing without CopperTab to decode it
• The connected Stripe account

That is the complete list of what CopperTab sends. CopperTab-authored payloads include no plan name, medication, diagnosis, program description, invoice line item, payer name, email, billing address, or clinical note. Card details are entered by the payer directly in Stripe-controlled fields. The Stripe dashboard for your account will show a list of charges with amounts and dates. It will not show anything that would identify a patient's condition or treatment.

How card entry works

When a patient enters their card number, that entry happens through Stripe's own hosted card fields. Card details pass from the payer's browser directly to Stripe. They never pass through CopperTab's servers.

Because card numbers never pass through CopperTab's servers, this substantially reduces PCI DSS scope. Practices remain responsible for their applicable PCI obligations.

What CopperTab receives after the patient enters their card is a token, a reference CopperTab can later hand back to Stripe to initiate a charge. The token is a Stripe reference, not a card number. Stripe holds the card details.

Why the separation matters for HIPAA

HIPAA generally requires a covered entity to have a BAA with any vendor that creates, receives, maintains, or transmits PHI on its behalf (see HHS guidance on business associates). If clinical billing detail reaches a system with no BAA, that may be an impermissible disclosure. Ask your counsel.

CopperTab is designed to prevent PHI from being sent to Stripe, enforced through field-level allowlists in CopperTab's Stripe payload code rather than left to configuration or to people remembering what not to send. The BAA you sign with CopperTab covers the data in the vault. Stripe, for these transactions, operates as a neutral payment execution layer.

Putting it together

The architecture is the product.

CopperTab is not a policy or a best practice or a reminder to “be careful with PHI.” It is a layer of infrastructure whose job is to hold your clinical billing context in a HIPAA-covered environment and send Stripe only what a payment processor needs to do its job. The two systems are separated by design, not by discipline.

Not sure what your current setup sends? Start with our 5-minute test. And if you want to see this working with your own Stripe account, book a 30-minute call.