HIPAA compliant credit card processing explained

Last updated: 29 May 2026

US reader? See the US version of this guide with US-specific compliance detail (TCPA, NYDFS, CCPA, FedNow, US PCI scope guidance).

Search "HIPAA-compliant credit card processing" and the first page of results reads like every vendor on it has a gold seal of approval from Health and Human Services. None of them do, because HHS doesn't hand out seals. The phrase gets used loosely, and healthcare procurement teams get burned by it constantly. Here's what it actually has to mean to be worth anything, written for UK readers who deal with US healthcare partners, US-headquartered parent groups, or transatlantic patient billing flows.

We're a UK telephone-payments business. We don't sell into US clinics directly. But because UK healthcare-adjacent organisations — private clinics with US insurer contracts, life-sciences companies handling US patient data, UK-based revenue-cycle outsourcers — get asked HIPAA questions during procurement, the same myths show up in our pipeline as they do in US vendor RFPs. The framework below is the one we use when those questions land.

There is no HIPAA certification#

HHS, the Office for Civil Rights that enforces HIPAA, does not certify vendors. There is no registry, no logo, no audit stamp you can rely on. A vendor claiming to be "HIPAA certified" is, at best, using shorthand for "we've been through a third-party audit." At worst, it's marketing copy with nothing behind it.

HIPAA compliance is a status, not a qualification. A covered entity is HIPAA-compliant if it meets the Privacy, Security, and Breach Notification Rules in practice. A business associate is HIPAA-compliant on the same terms plus a signed BAA with each covered entity it serves. That's the whole framework.

Why the "certified" claim keeps reappearing

Three reasons. First, healthcare buyers want a single tick-box. PCI has QSA-issued AoCs and SOC 2 has signed reports — both are real artefacts. HIPAA has neither at the federal level, so vendors invent something that looks similar. Second, HITRUST CSF certification gets conflated with HIPAA certification in marketing copy. HITRUST is a useful control framework and a real audit, but it's a private-sector scheme, not an HHS endorsement. Third, procurement teams under time pressure accept the shorthand because pushing back on it feels pedantic. It isn't. It's the difference between contractual reality and a glossy PDF.

What a credible vendor offers instead

Skip the "certified" language and look for three concrete things. A signed BAA with terms you can actually live with. A SOC 2 Type II report from a recognised firm, current within the last twelve months, with controls mapped to the HIPAA Security Rule. And a clear architectural description of where PHI enters, sits, and leaves the vendor's environment. Any vendor that can hand all three over without a sales-engineering scramble has done this before. Anyone who can't hasn't.

HITRUST, SOC 2, and ISO 27001 — what each one actually proves

SOC 2 Type II proves the vendor operated stated controls over a period (usually six to twelve months) without significant exceptions. HITRUST CSF certification proves the vendor's controls map to a healthcare-specific framework that incorporates HIPAA, NIST, and other standards. ISO 27001 proves the vendor runs a certified information-security management system. None of these is "HIPAA compliance" in the regulatory sense — that status only exists in the relationship between you, the vendor, and the BAA you've signed. They're useful evidence of operational maturity. They aren't substitutes for the BAA itself.

What the label actually has to cover#

For a credit card processor to be legitimately described as HIPAA-compliant in a healthcare setting, four things have to be true. The vendor signs a Business Associate Agreement without excessive carve-outs. The vendor's systems handle PHI, where PHI is present, in line with the HIPAA Security Rule's administrative, physical, and technical safeguards. The vendor has a breach-notification process that can meet the 60-day clock. And the vendor's subcontractors are flowed-down under the BAA so nothing falls out of scope.

Miss any of those and the label doesn't stick.

The BAA: read the carve-outs

Most vendor BAAs are written by the vendor's lawyers and protect the vendor's commercial interests. If you're new to this contract, our explainer on what a Business Associate Agreement actually is walks through the required clauses in plain English. The most common problem clauses are: a cap on indemnity that's lower than the realistic cost of a breach, a unilateral right to amend the BAA on 30 days' notice, exclusion of subcontractor liability ("we're not responsible for what our cloud provider does"), and a refusal to support breach notification beyond a standard timeframe regardless of the actual investigation. Healthcare counsel should redline each of those before signing.

Administrative, physical, and technical safeguards in practice

The Security Rule's three safeguard categories sound abstract until you map them to real vendor questions. Administrative safeguards: who at the vendor has access to your data, how is access reviewed, what happens when an admin leaves. Physical safeguards: where are the servers, who can walk into the data centre, what's the destruction process for retired drives. Technical safeguards: how is data encrypted in transit and at rest, what's the key management process, how are logs reviewed for anomalous access. A vendor that can answer each of these in specifics (encryption library, KMS provider, retention policy) is operating at the level HIPAA requires. A vendor that says "we use industry-standard encryption" hasn't told you anything useful.

Breach notification: the 60-day clock and why it slips

HIPAA's Breach Notification Rule gives covered entities 60 days from discovery to notify affected individuals, and the real-world fines from payment-processing breaches show why that clock matters. That clock starts when the entity "knows or, by exercising reasonable diligence, would have known" of the breach. The clock doesn't reset just because the vendor took two weeks to confirm the scope. This is why your BAA needs to specify how fast the vendor will notify you of a suspected incident, what level of detail the initial notice will contain, and how the vendor will support your investigation. A vendor that promises notification "promptly" without a defined timeframe has given you nothing enforceable.

Flow-down to subcontractors

If your business associate uses a subcontractor that touches PHI — a cloud provider, a backup service, an email gateway — that subcontractor is also a business associate and needs a BAA with the vendor. The flow-down is required by the HIPAA Omnibus Rule. The practical problem is that most large cloud providers will sign a BAA with the vendor but cap their own liability heavily. That cap doesn't reduce your exposure to OCR. It just means the vendor is sitting on more residual risk than they probably realise.

Curious how Paytia fits in? Have a quick chat with us — we'll show you in 15 minutes whether we're a fit.

Card data alone is not PHI#

This is the nuance that matters, and it cuts both ways. A 16-digit card number, on its own, is PCI-regulated data but it is not PHI. A credit card processor that only ever sees a tokenised card with no patient identifier, no procedure code, and no account link back to a treatment episode is not handling PHI.

The moment that card is paired with a patient name on a statement, an invoice that references a procedure, or a CRM record that ties to a care event, it becomes part of a "designated record set" in HIPAA terms and the PHI obligations kick in. The context is what makes data protected, not the card digits themselves. Our deeper piece on healthcare payment processing and HIPAA covers where that line sits in practice.

This is why the exact architecture of the payment vendor matters. A processor that receives a PAN plus nothing else, via a DTMF masking pipeline, may not be a business associate at all. A processor that also ingests your CRM data, or records calls containing PHI, absolutely is.

The 18 HIPAA identifiers, in payments context

The Privacy Rule lists 18 identifiers that make data PHI when combined with health information: names, geographic subdivisions smaller than a state, dates relating to an individual, phone numbers, email addresses, social security numbers, medical record numbers, account numbers, certificate or licence numbers, vehicle identifiers, device identifiers, web URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying number. Card numbers fall under "account numbers" — but only when paired with health information. A raw PAN with no patient context is just a PAN. A PAN sitting next to a chart number is PHI. That's the line.

Tokenisation as a scope-reduction tool

If the card processor never receives the raw PAN — only a token issued by a gateway — and never receives a patient identifier alongside it, the processor isn't handling PHI. Tokenisation moves the actual card data out of the processor's environment and replaces it with a meaningless reference. Combined with PHI segregation (the topic of the next section), this is what lets a card processor stay outside the BAA requirement while still being part of a healthcare workflow.

Where the line gets blurred

Three places where buyers get caught out. Call recordings: if the recording captures the full conversation including the treatment discussion, the recording is PHI even if the card portion is masked. CRM integrations: if the payment vendor's gateway sends the transaction reference back into a CRM record that also contains diagnosis or treatment data, the gateway has to be considered in scope for the BAA. Statement-by-email services: if the vendor generates and sends patient statements that include service descriptions, those statements are PHI from the moment they're generated, not from the moment they're sent.

Common vendor myths#

Three claims to be sceptical of. "We're HIPAA-compliant by design" usually means the vendor hasn't thought about BAAs. "PCI compliance covers HIPAA" is simply wrong: PCI covers card data, HIPAA covers patient data, and the Venn diagram isn't a circle — the HIPAA + PCI overlap for healthcare contact centres is where most buyers get caught out. "We don't need a BAA because we don't touch PHI" may be correct, but only if you can prove the PHI never enters the vendor's environment — which means auditing the call flow, the recording path, and the CRM integration.

For card processing specifically, if your calls are recorded and the recording sits with the vendor, the vendor needs a BAA. If the vendor processes payment metadata that includes a patient identifier, the vendor needs a BAA. If the vendor's support staff can see anything that links a card to a patient, the vendor needs a BAA.

"We're hosted on AWS so we're HIPAA-compliant"

AWS, Azure, and Google Cloud all offer HIPAA-eligible services and will sign BAAs with their customers. That makes the underlying infrastructure capable of supporting HIPAA workloads. It does not make whatever is running on top of that infrastructure HIPAA-compliant. The application code, the access controls, the logging, the backup processes — those are the vendor's responsibility, not the cloud provider's. A vendor that points to its cloud provider's BAA as evidence of compliance has either misunderstood the shared-responsibility model or is hoping you have.

"Our staff signed NDAs so PHI is protected"

NDAs protect the vendor from staff leaking confidential information. They do nothing about HIPAA. The Security Rule requires specific administrative safeguards: workforce training, access management, sanction policy, incident response. A vendor with NDAs but no HIPAA training programme has the wrong control in place. Ask to see the training records and the access-review log.

"We've never had a breach"

The absence of disclosed breaches isn't evidence of strong controls. It could mean strong controls; it could mean the vendor hasn't been targeted yet; it could mean the vendor hasn't noticed. The relevant question is "how would you know you'd been breached, and how fast." A vendor that can describe their SIEM, their alerting thresholds, and their incident-response runbook in detail has thought about this. A vendor that says "we monitor 24/7" without specifics hasn't.

Due-diligence checklist#

Before signing with any healthcare payment vendor, work through a structured HIPAA payment processor checklist covering all the bases — at minimum, ask them: will you sign our BAA or do you only offer your own template; how does your architecture segregate PHI from non-PHI; who at your company can access recordings or CRM integrations; what's your breach-notification SLA; are your subcontractors flowed-down; and can you provide a current SOC 2 Type II report and a most-recent PCI AoC.

If the vendor hesitates on any of those, the problem surfaces before go-live rather than during an OCR investigation. A vendor that's done this a hundred times has all six answers in a standard packet — and if you're unsure which BAA terms are negotiable, our BAA explainer covers the required clauses and the common carve-outs.

The questions buyers don't ask but should

Beyond the standard six, three questions sort the serious vendors from the rest. What's your data-residency story — where exactly does PHI sit and can you guarantee it stays in the US (or, for UK partners with US dependencies, what's the cross-border transfer mechanism)? What's your retention and deletion policy — when a covered entity terminates the relationship, how long does it take to fully purge PHI and how is that confirmed? What's your insurance position — cyber and tech E&O limits, deductibles, named insured. A vendor that can't answer those is a vendor that hasn't been through a serious procurement before.

Evidence vs. assertions

"We have controls in place" is an assertion. "Here's the SOC 2 report, here's the page describing the control, here's the test result" is evidence. Push for evidence wherever possible. A vendor that produces a one-page "compliance summary" but won't share the underlying report is hiding something — usually exceptions in the report or a scope that excludes the system you care about. Ask for the full report under NDA. If they refuse, that's data.

Reference calls with active customers

Ask for two reference calls with current customers in healthcare. Specifically: customers in the same regulatory bucket as you (covered entity vs. business associate), at similar scale, who've been live for at least twelve months. Vendors will offer their best references, which is fine — what you're listening for is whether the vendor's described capabilities match the reference's lived experience. If the vendor promised 24/7 phone support and the reference says "we mostly email them," that's a gap worth understanding before signing.

The workable pattern#

The design most US healthcare operators end up with isolates cardholder data from PHI at the architectural level. Card digits come in over a masked channel that never touches the CRM. Patient identifiers and procedure codes stay in the clinical system. The payment reference comes back as a token that links the two at query time rather than at storage time. Recording is selective: the conversation about treatment can be kept for HIPAA purposes, the card digits never enter the recording.

That pattern lets a card processor be genuinely "HIPAA-compliant" without needing a BAA in some cases, because the vendor never actually ingests PHI. Where the vendor does touch PHI, the BAA is there. It's cleaner, cheaper to audit, and less brittle.

Architectural separation in detail

The clean pattern has four distinct planes. The clinical plane holds the EHR, the CRM, and any treatment-related data — it's covered by your HIPAA controls and your direct BAA with the EHR vendor. The card-data plane is where the PAN briefly exists during capture — it's covered by PCI DSS v4.0.1 and sits inside the card processor's certified environment. The recording plane captures the conversation but explicitly excludes the card-entry portion — it sits in a HIPAA-covered environment because the conversation often includes PHI. The reference plane is where the token returns and links to the clinical record — it lives in the clinical plane, never in the card plane.

When those planes are properly separated, each one is governed by the right framework. You don't end up with PCI auditors reviewing patient records or HIPAA auditors trying to assess your card-tokenisation flow. The audits stay scoped to the data they're meant to cover.

Why "everything under one BAA" is a worse pattern

Some vendors offer to put their entire platform under BAA, regardless of whether parts of it touch PHI. That sounds convenient but creates two problems. First, it dramatically expands the vendor's HIPAA audit surface, which usually shows up as higher pricing and slower change-management. Second, it muddies your data-flow diagram: when everything is in scope, nothing is really in scope, and that's where compliance failures hide. Sharp scope boundaries are easier to audit and easier to defend.

Cross-border patterns for UK organisations

UK private clinics that bill US insurers, UK life-sciences firms with US trial sites, and UK-based outsourcers serving US providers all face the same data-flow question: where does US patient data actually sit, and what's the legal mechanism for moving it across the Atlantic? Post-Schrems II, the EU-US Data Privacy Framework and the UK extension provide a legal basis, but only for participating US data importers. The practical pattern most regulated UK organisations adopt: keep US patient data in US-hosted environments, run UK operations against the same data via authenticated access from the UK rather than copying it across, and document the transfer impact assessment regardless of the legal basis chosen. Your card processor's data-residency answer matters here. Ours is one of the data points we routinely supply during UK procurement for organisations with US healthcare exposure.

When a BAA is required and when it isn't#

The threshold isn't "does the vendor process payments for healthcare." It's "does the vendor create, receive, maintain, or transmit PHI on behalf of the covered entity." The distinction matters because BAAs are contractual commitments with real audit and liability consequences, and asking a vendor to sign one where PHI genuinely isn't flowing muddies the risk picture for both sides.

A gateway that receives only a tokenised PAN with no patient identifier, no procedure information, and no billing context usually sits outside the BAA requirement. The same gateway, integrated into a CRM that passes patient name and invoice detail alongside the card token, is inside the requirement. What changed isn't the vendor's product, it's the integration. This is why any healthcare payment architecture should start with a data-flow diagram and a clear answer to "what fields actually move across which system boundary."

The conduit exception, and why it's narrow

HHS has historically recognised a narrow "conduit exception" — entities that transmit PHI without storing it or accessing it in any meaningful way (the classic example is the postal service or an ISP). Some vendors try to claim this exception to avoid signing BAAs. The exception is genuinely narrow. If you store any PHI, even transiently, for any purpose other than pure transit, you're not a conduit. A payment gateway that holds tokenised data is almost certainly not a conduit. A clearing-only network that briefly carries authorisation messages without persisting them might be. When in doubt, sign the BAA.

Indirect exposure routes

Three patterns where vendors accidentally end up handling PHI without realising. Support tickets: a customer-service rep at the vendor pastes a transaction log into a ticket that includes the patient name from the invoice line. Backup retention: the vendor's daily backup captures CRM data the vendor's runtime systems don't actually use. Analytics pipelines: anonymised dashboards turn out to include sufficient identifiers that re-identification is feasible. Each of these can drag a "non-PHI vendor" into PHI territory. The BAA needs to cover them, or the architecture needs to prevent them.

UK-specific BAA equivalents

For UK-only workflows, the HIPAA BAA doesn't apply — the controlling regime is UK GDPR plus the Data Protection Act 2018, with the ICO as regulator. The closest equivalent contract is the Article 28 data-processing agreement (DPA). Buyers occasionally try to apply HIPAA terminology to UK workflows, which causes friction with UK vendors who have perfectly good DPA templates ready to sign. If you're a UK organisation with no US patient data, what you need is a DPA, not a BAA. If you have both, you need both, and the documents need to reference each other to avoid contradictions.

Telephone payments in a HIPAA setting#

For phone-based payments specifically, the BAA question depends almost entirely on the call-recording and call-handling architecture. If the call is recorded and the recording sits with the telephony vendor, the telephony vendor handles PHI because the conversation includes treatment context, and the BAA is required. If the card portion of the call is masked with DTMF suppression, the card data never enters the card processor's systems, so the card processor may be able to stay out of scope even while the telephony vendor stays in.

This is exactly the split most well-architected healthcare payment deployments use. Telephony and recording sit in a HIPAA-covered environment under BAA. Card processing sits in a PCI-covered environment that never touches PHI. The customer experience is a single uninterrupted call, but the regulatory surface area is split sensibly between the two frameworks.

If you're building or reviewing a US healthcare payment workflow, our telephone payment platform is designed around exactly this split. Same approach we take for every regulated industry: keep the data out of systems that don't need it, and whatever does touch it is under the right contract.

DTMF masking: what's actually happening

When the patient enters their card digits on the keypad, the tones (DTMF) are intercepted before they reach the agent's headset or the call recording. The processor captures the digits, tokenises them, and returns a payment result. The agent hears flat tones during card entry, sees the masked digits redacted, and the recording captures the same redacted version. The conversation either side of the card-entry portion is captured normally. This is the architecture that makes the clean split possible. We've written more about the mechanics in our DTMF masking glossary entry if you want the technical detail.

Why screen-share-based patterns are worse for HIPAA

Some alternative phone-payment models ask the agent to remote into the patient's screen, or to read card digits from a shared form. Both patterns expose the agent to the card data and create recording-capture risk. Both also tend to require the patient to navigate a web form during the call, which is a usability problem and a fraud-risk problem. The DTMF-masking pattern keeps the patient on the phone, the card data away from the agent and the recording, and the conversation flowing naturally. For HIPAA-adjacent workflows where the conversation often includes treatment context, that separation is exactly what you want.

Contact-centre platforms and where they fit

Modern contact-centre platforms — Genesys Cloud, Five9, NICE CXone, Talkdesk, RingCentral, 8x8, Amazon Connect — sit in the telephony plane. Our deeper guide on running HIPAA and PCI compliance side by side in a healthcare contact centre covers exactly how the two frameworks coexist on the same call. They handle the call, the recording, the agent desktop, and the CRM integration. They need to be inside the HIPAA-covered environment, with a signed BAA. The card-payment vendor integrates with the contact-centre platform at the point of card capture, sits in a separate PCI-covered environment, and stays outside the BAA in clean architectures. Most major contact-centre platforms support this integration pattern out of the box, and most will sign a BAA for the telephony layer. If a contact-centre vendor refuses to sign a BAA, the deployment can't support HIPAA-regulated calls without significant compensating controls.

UK PCI DSS v4.0.1 alignment

The card-payment side of the architecture is governed by PCI DSS v4.0.1, which became the only valid version in March 2025 after v3.2.1 was retired. Key v4.0.1 changes that matter for phone-payment deployments: explicit requirements around scope definition (Requirement 12.5.1), targeted risk analyses for many controls, and stronger requirements for service-provider transparency. For UK organisations subject to PCI through their acquiring bank's contract, v4.0.1 applies regardless of whether HIPAA also applies. The two frameworks coexist; they don't substitute for each other.

How to phrase the RFP question#

If you're writing a healthcare payment RFP and want to cut through vendor marketing quickly, the most useful single question is: "Describe the exact path that a recorded billing call takes through your infrastructure, including every subcontractor, and identify which parts of that path ingest PHI as defined by 45 CFR §160.103." A vendor that's built for healthcare answers this in a paragraph. A vendor that hasn't thought about it answers in generalities, asks for clarification, or provides a canned compliance statement. That one question, in our experience, sorts the shortlist faster than any checklist.

Follow-up questions that separate vendors

Once you've got the data-flow answer, three follow-ups reveal whether the vendor has actually operated the architecture in production. "Walk me through your last security incident, anonymised — what was detected, when, by whom, and what changed afterward." "How many BAAs have you signed in the last twelve months, and what's the most contentious clause in your standard template." "If I terminated tomorrow, what's the timeline and process to confirm full deletion of PHI, and what evidence do you provide." Each of these is hard to bluff. A vendor that's lived through real procurements has lived answers.

Red flags in vendor responses

Watch for these patterns. The compliance answer comes from someone titled "Compliance Lead" who isn't on any other call — they're a sales prop, not an operator. The data-flow diagram is missing or comes back days later — the vendor doesn't have one and is drawing it for you. The BAA template is non-negotiable — that's a sign you'll have no use on anything else either. The vendor offers to "white-label our compliance posture" — they're hoping you don't notice that you're now the named entity on a control they don't actually operate.

How to score the responses

Build a simple matrix: BAA willingness and quality, architectural clarity, evidence depth, breach-process specificity, subcontractor flow-down, residency and deletion answers, reference-call alignment. Score each from 0 (nothing useful) to 3 (concrete and evidenced). Anything scoring below 2 on BAA, architecture, or breach is a hard fail regardless of the rest of the matrix. The remaining shortlist is usually two or three vendors, which is when commercial conversations start being productive.

Where Paytia sits in this picture#

We're a UK-based telephone payment platform. We use DTMF masking at the card-capture point so the agent never sees or hears the card digits and the recording captures a redacted version. For UK organisations with US patient-billing exposure or US healthcare partners, we operate the card-data plane only — we don't ingest PHI in the standard configuration, which keeps the BAA conversation focused on the telephony provider rather than us.

For UK-only deployments, we're governed by UK GDPR, the DPA 2018, PCI DSS v4.0.1, and our acquiring relationships — the same framework that applies to any UK card processor working with regulated industries. If you're building a healthcare payment workflow that touches both jurisdictions, we'll happily sit alongside whichever HIPAA-covered telephony provider you've selected and document the boundary in writing.

Curious how Paytia fits in? Have a quick chat with us — we'll show you in 15 minutes whether we're a fit.

Related guides in this cluster#