HIPAA-Compliant Credit Card Processing: The Honest Guide

Last updated: 27 May 2026

Search "HIPAA-compliant credit card processing" and the first page of US results reads like every vendor on it carries a gold seal from Health and Human Services. None of them do, because HHS doesn't hand out seals. The phrase gets used loosely in marketing copy, and healthcare procurement teams get burned by it constantly. This guide walks through what the label actually has to mean if it's worth anything, where HIPAA and PCI DSS overlap on a US billing call, and the specific questions to ask a processor before you sign.

This piece sits one level deeper than our broader HIPAA and payment processing guide. That one covers the full healthcare payments picture. This one zeroes in on the credit card side of HIPAA compliance — vendor selection, BAAs, and the architecture that keeps card data out of your protected health information environment. If your operation also runs claims adjudication or premium collection, the claims processing software guide covers the workflow side and where the BAA needs to land in that flow.

There's no HIPAA certification programme — and why that myth costs healthcare buyers money#

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

The myth persists because it's a useful sales hook. "HIPAA-certified payment processor" sounds definitive. "HIPAA-compliant given the right architecture and a signed BAA" sounds like work. So the marketing teams reach for the shorter line, the procurement teams paste it into their RFPs, and the cycle continues.

HIPAA compliance is a status, not a qualification you earn once and frame on the wall. A covered entity — a hospital, clinic, dental practice, health plan, or healthcare clearinghouse — is HIPAA-compliant if it meets the Privacy Rule, Security Rule, and Breach Notification Rule in practice. A business associate is HIPAA-compliant on those same terms plus a signed Business Associate Agreement with each covered entity it serves. That's the whole framework. Anything else is a vendor claim, not a regulatory finding.

What's actually behind a "HIPAA certified" badge, when there's anything behind it at all, is usually one of three things: a SOC 2 Type II report (audit of operational controls — useful but not HIPAA-specific), a HITRUST CSF certification (a private framework that maps to HIPAA but isn't HIPAA itself), or a vendor self-attestation. None of these is OCR saying the vendor is compliant. None of these protects you in an OCR investigation. They're all useful evidence in vendor due diligence — but they aren't a replacement for the BAA and the architecture that puts the BAA into practice.

The Office for Civil Rights publishes guidance, investigates breaches, and issues civil monetary penalties — it doesn't approve vendors in advance. So when a sales deck shows a "HIPAA-compliant" badge, treat it the way you'd treat any other vendor self-claim: ask what it's actually based on, look for the underlying audit reports, and read the BAA before deciding whether the vendor's risk posture matches yours.

What "HIPAA-compliant" actually has to cover#

For a credit card processor to be legitimately described as HIPAA-compliant in a US 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 genuinely 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 under 45 CFR §§164.400-414. And the vendor's subcontractors are flowed-down under the BAA so nothing slips out of scope when a third party touches the data.

Miss any of those four and the label doesn't stick. It's not enough to have encryption at rest, or to have completed a SOC 2 Type II, or to be PCI DSS Level 1. Those are necessary controls, not the same thing as HIPAA compliance.

HIPAA, in 90 seconds#

HIPAA is the Health Insurance Portability and Accountability Act, passed in 1996. The pieces that matter for payments are the Privacy Rule (1996), the Security Rule (2003), and the Breach Notification Rule (2009, added by the HITECH Act). Enforcement is by HHS OCR, with parallel authority for state attorneys general to bring actions on behalf of state residents.

HIPAA penalties are tiered. Tier 1 covers unknowing violations where the covered entity didn't and couldn't reasonably have known. Tier 4 covers wilful neglect that wasn't corrected. After the 2023 OCR penalty adjustment for inflation, civil monetary penalties run from roughly $137 per violation at the bottom to $2,067,813 per violation at the top, with annual category caps reaching $1,919,173 per identical violation category. The historical settlements that get cited in board decks — Anthem at $16M in 2018, Memorial Healthcare at $5.5M in 2017, Premera Blue Cross at $6.85M in 2020 — are still the reference points for what a major breach actually costs, and they're not the worst-case outcomes.

Card data alone is not PHI#

This is the nuance that catches both buyers and vendors out, and it cuts both ways. A 16-digit card number on its own is PCI-regulated data — but it isn't PHI. A processor that only ever sees a tokenized card with no patient identifier, no procedure code, and no link back to a treatment episode is not handling PHI and arguably isn't a business associate at all.

The moment that card is paired with a patient name on a statement, an invoice that references a specific 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 engage. Context is what makes the data protected, not the card digits themselves.

This matters commercially because it changes which vendors in your stack actually need a BAA. A gateway that receives only a tokenized PAN with no patient context might sit 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.

Where PCI DSS and HIPAA overlap#

Both rulebooks apply at the same time on a US healthcare billing call, and they were drafted by different bodies for different reasons. PCI DSS governs cardholder data: PAN, expiry, service code, CVV, PIN. HIPAA governs protected health information: anything that identifies a patient and relates to their health, treatment, or payment for treatment. The word "payment" in HIPAA explicitly covers billing, collections, and insurance eligibility — which is exactly what a billing call is.

If your agent is on a call that touches a procedure, diagnosis, or treatment AND captures a card, that one call contains both PHI and cardholder data. The recording holds both. The CRM note holds both. The agent's desktop at that moment holds both. Your vendor list needs to be PCI-compliant AND under a BAA, because either gap is a breach waiting to happen. Our piece on PCI compliance for telephone payments walks through how recordings drag systems into PCI scope in detail.

Both standards demand risk assessment, access controls, encryption, and audit logs. HIPAA is more prescriptive about who can see what. PCI is more prescriptive about how the card data is stored and transmitted. The intersection isn't theoretical — it's the audio file sitting on your contact center's recording server right now.

The BAA — what it has to cover#

The Business Associate Agreement is the contract HIPAA requires between a covered entity and any vendor that creates, receives, maintains, or transmits PHI on the entity's behalf. The legal basis is 45 CFR §164.502(e), and HITECH 2009 extended the requirement so business associates also need BAAs with their own subcontractors. There's no "trust us" path — if PHI moves, the BAA moves with it.

A workable healthcare BAA covers, at minimum, the permitted and required uses of PHI; safeguards (encryption in transit and at rest, access controls, audit logging); breach notification — typically within 60 days of discovery, often tighter by contract; audit rights for the covered entity; subcontractor flow-down; and the handling of PHI on termination (return, destruction, or extended protection if return isn't feasible).

Vendor templates vary. Some are tight and standard. Others carve out so much that the BAA is effectively cosmetic. Three carve-outs to push back on: indemnity caps so low they're meaningless; subcontractor exceptions that exclude the vendor's own infrastructure providers; and breach-notification windows that quietly extend past 60 days. A BAA that protects the vendor more than the patient isn't worth the e-signature.

BAA must-haves — the clauses to redline before signing#

If you read nothing else in your vendor's BAA template, read these clauses with care.

The permitted uses and disclosures section defines exactly what the vendor can do with PHI. The HIPAA-required language allows uses necessary to perform the services in the underlying services agreement, plus management and administration of the vendor's own business. Watch for templates that broaden this to "and any other purpose permitted by law" — that's a loophole big enough to drive a marketing analytics product through.

The safeguards clause should reference the HIPAA Security Rule's administrative, physical, and technical safeguards by name, and the vendor should either commit to specific controls (AES-256 at rest, TLS 1.2+ in transit, MFA for privileged access, audit logging retained for at least six years) or commit to maintaining safeguards consistent with the Security Rule and SOC 2 Type II. The weakest version is "reasonable and appropriate safeguards" with no specifics — that's a phrase to leave you arguing in front of OCR about what "reasonable" meant.

The breach notification clause is where many vendor templates quietly extend the timeline. HIPAA gives covered entities 60 days from discovery to notify patients; the vendor's notification timeline to you needs to be much shorter so you have time to investigate, assess the four-factor risk standard, and notify. Push for vendor notification within 5 business days of vendor discovery, with the option to compress further if the vendor's facts indicate a major incident. "Without unreasonable delay" is too soft.

The subcontractor flow-down clause requires the vendor to bind any subcontractor handling PHI to terms at least as restrictive as the vendor's BAA with you. Ask for the actual subcontractor list — cloud provider, telephony carrier, recording platform, AI vendors, analytics vendors. Ask whether you'll be notified of additions or changes. Ask whether the vendor indemnifies you for breaches caused by a subcontractor with an inadequate downstream BAA.

The termination clause has to address what happens to PHI when the contract ends. The HIPAA-required language calls for return or destruction; the "if not feasible" exception gets used too broadly. Ask what specifically isn't feasible (backup tapes, immutable audit logs, legal-hold data are the legitimate exceptions), how long the residual data lives, and what protections continue to apply to it.

The audit rights clause should let you commission an independent audit at your cost, with the report shared, and a separate right to inspect after a declared breach. Limits on frequency ("no more than once per year") are reasonable; outright exclusion of audit rights is not.

The indemnification clause is where the financial blast radius gets defined. Vendor caps at 12 months of fees are common and almost always inadequate for breach scenarios — a $24,000 cap against a multi-million-dollar OCR settlement is meaningless. Push for either uncapped indemnity for HIPAA breaches specifically, an indemnity scaled to the number of records the vendor processes, or at minimum a multiple of fees with a hard floor.

Dual-scope PCI plus HIPAA architecture#

The cleanest way to keep both rulebooks satisfied is to design the data flow so the two regulated data types never sit together in any system you operate.

The PHI path covers everything to do with the patient identity, the treatment, the eligibility check, the statement, the call recording, and the CRM note. It runs through your EHR, your patient accounting system, your contact center platform, your call recording infrastructure, and your CRM. Every vendor in that path needs to be under a BAA. The technical controls are the HIPAA Security Rule's administrative, physical, and technical safeguards.

The PAN path covers the card number, expiry, CVV, and any card-on-file token. It runs through the payment capture surface (DTMF masking, hosted IVR, web payment form), the payment gateway, and the acquirer. Every vendor in that path needs to be PCI DSS Level 1 certified. The technical controls are the PCI DSS v4.0.1 requirements.

The trick is making these two paths intersect only through opaque references. The PHI system holds a patient ID and an invoice ID. The PAN system holds a token and a transaction ID. The transaction record links the invoice ID to the transaction ID — not the patient name to the card digits. If a breach hits either system in isolation, the other side of the regulated data isn't exposed.

This sounds straightforward in the diagram. In practice, it means redesigning a few things that probably exist in your current setup. Call recordings that capture both sides of the conversation have to lose the DTMF capture window — either pause-and-resume during typing, or full DTMF masking that suppresses the tones in-flight. CRM notes have to stop combining card descriptors ("paid $240 on Visa ending 4242") with treatment context. Agent screens have to either show patient detail or card detail but not both at once during the payment moment.

The patterns that make this work are mature. Hosted IVR for after-hours payment. DTMF masking with split-channel recording for live agent calls. Tokenization for cards on file with the token stored in the PHI system and the card data living in the PAN system. None of this is new; what's hard is the discipline to insist on it during vendor selection rather than trying to retrofit it after a breach.

Telephony-specific HIPAA risks — the call recording problem#

The single biggest source of HIPAA exposure in a contact center is the call recording stack. The recording itself is PHI when the call touches treatment. The transcript is PHI if you've enabled speech-to-text. The voice biometric in the audio is PHI because voice prints are listed in the 18 HIPAA identifiers. The metadata — phone number, timestamp, duration, agent ID — is PHI when paired with a treatment context.

Most US contact centers run their recording infrastructure on a platform like a major CCaaS provider. The platform itself sits in someone else's cloud. The recordings get processed by a speech analytics vendor. The transcripts feed into a QA workflow. Each one of those steps is a vendor handling PHI on your behalf, and each one needs a BAA.

A common failure mode: the contact center platform has a BAA, the recordings are encrypted, the access controls are in place. But the speech analytics vendor doesn't have a BAA because the buyer thought of it as a productivity tool rather than a system that touches PHI. Now you have a parallel PHI database (the transcripts) sitting with a vendor that doesn't know it's a business associate. OCR has reached settlements against covered entities for exactly this pattern.

The card-data side of the same problem is what DTMF masking exists to solve. If the patient reads card numbers out loud during the recording, the recording now contains cardholder data and the recording infrastructure is in PCI DSS scope on top of HIPAA. DTMF masking removes the card data from the audio entirely — the tones never reach the recording server, the transcript has nothing to transcribe, and the recording stays in pure HIPAA scope rather than the dual-scope mess.

The other failure mode worth naming is warm transfers. Agent A summarizes the patient's situation for Agent B before connecting. If that handoff is recorded and the recording's retention or access doesn't match the original consent, you've expanded the disclosure circle. Either script the handoffs to share only what Agent B needs, or pause recording during the handoff.

What to ask in a vendor RFP — the questions that surface the gaps#

A standard healthcare payment RFP usually asks the obvious things: PCI certification, encryption, uptime, references. The questions that actually separate vendors are sharper.

1. Will you sign our BAA template, or only your own? Vendors that only sign their own template are usually selling at scale and don't want negotiation overhead. Fine, but ask for the redline history on their template and the range of carve-outs they've accepted before. A vendor that says "our BAA is non-negotiable" should be asked what specifically they mean.
2. What's the breach notification SLA you'll commit to in writing? Anything beyond 5-7 business days from vendor discovery is too slow given your 60-day clock with patients.
3. Provide your complete subprocessor list — every entity, every jurisdiction. Cloud (AWS, Azure, GCP region), telephony carrier, recording infrastructure, speech-to-text, AI/ML services, analytics, monitoring. If they hesitate, the list isn't being maintained.
4. What's your data-flow diagram for a healthcare card payment? A vendor that can't draw the flow on a whiteboard hasn't thought through PHI segregation. Ask them to walk through what data lives where and which system holds what reference.
5. Provide your most recent SOC 2 Type II report and your current PCI DSS Attestation of Compliance. Read the scope section, the exceptions, and the management response — not just the auditor's opinion page.
6. Have you had a HIPAA breach in the last five years? If yes, what happened, what was the root cause, what changed? If no, what's the closest call you've had and what was learned?
7. Who at your company can access our data? Named roles, access controls, logging. "Engineering on call" is a reasonable answer; "anyone with a corporate badge" is not.
8. How is access to our data logged and how long are the logs retained? HIPAA requires audit controls; ask what they look like in practice and whether you can request log extracts.
9. Can you provide a sample BAA you've signed with another covered entity? Redacted is fine. This tells you whether the vendor's BAA is a working document or a template that gets pulled out only when asked.
10. What's your incident response process? Named roles, escalation paths, decision authority. Ask for a sample incident timeline (redacted).
11. Reference checks with other covered entities of similar size and scope. Not the marketing references. Ask the reference what their privacy officer thinks of the vendor, not just the IT team.
12. What happens to our data when the contract ends? Specifically, the return-or-destroy clause and the residual-data exceptions. Get the timeline in writing.

If a vendor stumbles on more than two or three of these, the problem surfaces in the RFP rather than two years in during an OCR investigation. A processor that's done this a hundred times has the answers ready in a standard packet they share under NDA.

The phone-payment scenario#

This is where a lot of US healthcare buyers actually live: patient on the phone with a billing agent, statement open, ready to pay an outstanding balance. The call is recorded for quality and dispute purposes. The conversation will reference the procedure, the insurance status, and the amount owed — all PHI. The patient then reads out a card number. Under the traditional model, that recording now contains both card data and PHI, which means it's regulated under PCI AND under HIPAA, and you need every vendor in the recording path covered by both.

The clean architectural fix is to take card payments over the phone with the card data captured outside your environment entirely. DTMF masking sits the customer's keypad tones inside a separate channel that routes straight to the payment processor. The agent stays on the line. The call recording captures the conversation but never the card digits. The CRM holds a token, not a PAN. The contact center drops out of PCI scope, and the HIPAA audit only has to cover the PHI side, which is what your existing controls are built for.

That same pattern is why DTMF masking shows up in almost every well-architected US healthcare payment deployment. The telephony and recording layer is HIPAA-covered and under a BAA, because the conversation contains PHI. The card processor is PCI-covered and may or may not need a BAA depending on whether any patient identifier crosses to it. Two regulatory frames, sensibly split, one uninterrupted call from the patient's perspective. Our card-not-present guide walks through the broader category of these phone-based payment flows.

Cost and pricing realities#

HIPAA-compliant credit card processing isn't free, but the bigger cost is almost always the audit and the architecture, not the per-transaction rate. Card processing fees in US healthcare run in roughly the same band as any other card-not-present merchant: interchange-plus pricing typically in the 0.05% to 0.30% range over interchange, plus per-transaction fees in cents. The HIPAA-specific costs sit elsewhere: BAA negotiation and legal review, vendor security questionnaires, annual SOC 2 reviews on each vendor in the path, the security risk analysis OCR expects you to refresh annually, and the engineering time to keep data flows clean as your CRM and telephony stack evolves.

The hidden cost of getting it wrong is bigger than any of that. The 2018 Anthem settlement at $16M, the 2020 Premera settlement at $6.85M, and the Memorial Healthcare resolution at $5.5M are visible because they're public. The corrective action plans that come with them — multi-year, monitored by OCR, requiring outside auditors — typically cost more than the fine itself. Compared with that, the price of doing the architectural work upfront looks small.

Common mistakes#

A few patterns we see often enough they're worth calling out.

The first is assuming generic credit card processors are HIPAA-compliant by default because they handle other regulated data. Most aren't. Major US acquirers vary widely in their willingness to sign BAAs, and the answer can be different depending on which integration product you're using and how much patient context crosses the API. "They handle card data, so they must be HIPAA-compliant" is not a position you can defend in an OCR investigation.

The second is not having BAAs in place across the full stack. The telephony platform is the one most often missed, because buyers think of it as infrastructure rather than as a system that touches PHI. If the call is recorded and the recording captures any treatment context, the telephony vendor is handling PHI on your behalf and needs a BAA. Same logic applies to your call analytics, your speech-to-text vendor, and any AI-assist or QA tooling sitting on top of the recordings.

The third is mixing PHI into CRM notes alongside card data. A note that says "Patient called re: oncology follow-up co-pay, paid $240 on Visa ending 4242" combines treatment context, payment amount, and a partial card reference in a single record. That note is PHI under HIPAA AND a PCI scoping concern, and it shouldn't exist in that form. Free-text agent notes are one of the biggest leakage points for both rulebooks, and the fix is usually structured fields plus agent training rather than more technology.

The fourth is treating the security risk analysis as a one-time project. The Security Rule requires an ongoing risk analysis, refreshed at least annually and whenever there's a material change in the environment. Vendors get added, integrations get rebuilt, recordings get retained longer, an AI tool gets switched on — each one of those changes the risk picture and should trigger an update. OCR investigators ask for the risk analysis early; "we did one in 2022" is not the answer that protects you.

The fifth is over-relying on encryption as the answer to everything. Encryption at rest and in transit is necessary, but it doesn't address access controls, audit logging, training, or the question of who can decrypt the data. "We encrypt it" doesn't satisfy the Security Rule on its own.

Where Paytia fits#

We're a PCI DSS Level 1 service provider, certified since 2016, with more than $500 million in card payments processed through our DTMF masking platform. Our US operation is based at 447 Broadway, 2nd Floor, New York. We do sign BAAs with US covered entities where the deployment warrants one.

The honest framing: we're a payment-side specialist, not a HIPAA workflow vendor. We don't store PHI, manage clinical records, or replace your EHR. What we do is keep cardholder data out of your contact center and your CRM, which materially reduces the HIPAA surface area you have to defend. The card flow goes customer's keypad to Paytia's PCI-covered infrastructure to your payment gateway. It doesn't touch your covered entity's systems with card data at any point. Whether you need a BAA with us depends on what other context crosses the integration — your account manager will walk through the data flow with you before either side commits.

If you're building or reviewing a US healthcare payment workflow, the underlying PCI DSS requirements haven't changed — but the way you meet them when HIPAA's also in the picture has. Architecturally separating card data from PHI is the simplest way to make both rulebooks line up.

FAQ#

Is there an official HIPAA-compliant credit card processor list from HHS?

No. HHS doesn't certify, accredit, or publish a list of compliant vendors. Any vendor claiming "HIPAA certification" is using marketing shorthand for a third-party audit, usually a SOC 2 Type II. The compliance status comes from how the vendor operates and what's in the BAA, not from a government register.

Does PCI DSS compliance mean a processor is HIPAA-compliant?

No. PCI DSS covers cardholder data; HIPAA covers protected health information. The two standards have some overlapping controls — encryption, access management, audit logging — but they regulate different data and have different enforcement bodies. A PCI DSS Level 1 service provider can still be unfit for healthcare if it won't sign a BAA or its architecture lets PHI leak across boundaries.

Do we need a BAA if the processor never sees patient information?

If you can demonstrate, with a data-flow diagram, that no patient identifier ever crosses to the processor — only a tokenized card and an opaque transaction reference — then a BAA may not be required for that specific vendor. In practice, most healthcare integrations pass at least patient name or invoice reference, so most processors do end up needing one. The safest default is to ask the vendor to sign a BAA and have your privacy officer review the data flow.

How long do we have to report a breach?

The HIPAA Breach Notification Rule (45 CFR §§164.400-414) requires covered entities to notify affected individuals within 60 days of discovering an unsecured PHI breach. Breaches affecting 500 or more individuals must also be reported to HHS within 60 days and disclosed to prominent media in the affected state. Breaches under 500 individuals can be logged and reported to HHS annually. State breach laws often add their own, tighter timelines.

What's the difference between HIPAA-compliant and HIPAA-friendly?

"HIPAA-friendly" is marketing. It usually means the vendor has some of the controls but won't sign a BAA, which for a healthcare buyer is a deal-breaker. If the vendor's answer to "will you sign a BAA" is vague, the product isn't fit for your environment regardless of what the brochure says.

Can we use a generic card processor for healthcare if we add our own controls?

Maybe, but the architecture has to keep PHI out of the processor's environment entirely — no patient identifier in the payment metadata, no recordings sent to the processor, no CRM integration that passes treatment context. If your billing flow can be redesigned to that standard, fine. If it can't, you need a vendor that's willing to sign a BAA and operate as a business associate.

Recent OCR enforcement — the cases that should be in your board pack#

The historical headline settlements (Anthem $16M in 2018, Premera $6.85M in 2020, Memorial Healthcare $5.5M in 2017) are still the reference points for what a major breach costs at the top of the range. But the 2023-2025 enforcement wave shows OCR shifting attention to the everyday failure modes — risk analysis, access controls, monitoring, and business-associate accountability — and the cost of each lesson is still seven figures all-in once corrective action plans and remediation are counted.

Banner Health paid $1.25M in 2023 over a 2016 cyberattack exposing PHI of 2.81 million people. The OCR finding cited inadequate risk analysis, weak access management, and missing audit controls. The two-year corrective action plan required an organization-wide risk analysis overhaul.

Yakima Valley Memorial Hospital paid $240,000 in 2023 after 23 security guards used a shared login to access PHI of 419 patients without legitimate purpose. The case is small in dollar terms but instructive — shared credentials and weak monitoring are exactly the kind of operational pattern OCR finds when it audits an organization that's never had a breach.

Doctors' Management Services paid $100,000 in 2023 in OCR's first-ever ransomware-specific settlement, covering a 2017 incident exposing 206,695 records. Ransomware is now an OCR enforcement category in its own right.

iHealth Solutions, a business associate, paid $75,000 in 2023 over a breach exposing 267 patients' records — notable because it's direct enforcement against a BA without the covered entity being separately fined. HITECH gave OCR this authority; OCR is now using it.

The pattern across these cases isn't sophisticated attacker tradecraft. It's missing risk analyses, weak access controls, slow detection, and inadequate monitoring. For a healthcare buyer evaluating processors, the relevant question is whether the vendor's controls would survive a similar OCR audit — not just whether they'd survive a determined attacker.

Frequently asked questions#

Is there a HIPAA-compliant credit card processor list from HHS?

No. HHS doesn't certify, accredit, or publish a list of compliant payment vendors. Any "HIPAA certified" claim is marketing shorthand for a third-party audit, usually a SOC 2 Type II or a HITRUST CSF certification. Those reports are useful evidence in vendor due diligence, but they're not a regulatory approval. A processor's compliance status comes from how it actually operates and what's in the Business Associate Agreement it signs with you. If a vendor's sales deck shows a HIPAA badge, ask what's behind it and read the BAA before deciding whether the risk posture fits your environment.

Does PCI DSS compliance make a processor HIPAA-compliant?

No. PCI DSS covers cardholder data; HIPAA covers protected health information. The two standards have some overlapping controls — encryption, access management, audit logging — but they regulate different data and have different enforcement bodies. A PCI DSS Level 1 service provider can still be unfit for healthcare if it won't sign a BAA or its architecture lets PHI leak across boundaries. Conversely, a BAA without strong PCI controls doesn't protect the card data when it's in scope. You need both, and you need to verify the vendor sits on the right side of each line.

What should a HIPAA BAA include for a payment processor?

A workable BAA covers permitted uses and disclosures of PHI, specific safeguards (AES-256 at rest, TLS 1.2+ in transit, MFA, audit logs retained for at least six years), a breach notification SLA from the vendor that's much shorter than your 60-day clock with patients, subcontractor flow-down naming the cloud provider and telephony carrier, audit rights including a right to inspect after a declared breach, and return or destruction of PHI on termination. Watch for indemnity caps at 12 months of fees — that's usually meaningless against a multi-million-dollar OCR settlement. Push for uncapped indemnity on breach scenarios.

How do I keep card data out of HIPAA scope on phone payments?

Design the call so card digits never enter your environment. DTMF masking is the standard fix — the patient stays on the line with the agent and types card details on their phone keypad. The system masks the tones so the agent hears flat beeps, captures the digits in a separate channel, and sends them straight to the payment gateway. Nothing card-related is written to the call recording, the agent screen, or the CRM. Your contact center drops out of full PCI scope, and the recording infrastructure stays in pure HIPAA scope instead of carrying both rulebooks at once.

What's the difference between HIPAA-compliant and HIPAA-friendly?

"HIPAA-friendly" is marketing. It usually means the vendor has some controls in place — encryption, access logging, maybe a SOC 2 report — but won't sign a Business Associate Agreement. For a covered entity that's a deal-breaker. Without a signed BAA the vendor isn't bound by HIPAA's flow-down requirements, you can't audit them, and any breach on their side leaves you holding the regulatory bag with OCR. If a vendor's answer to "will you sign a BAA" is vague, ambiguous, or pushed to a higher-priced tier, the product isn't fit for your environment regardless of what the brochure says.

Putting it all together — a 90-day vendor selection roadmap#

If you're starting from scratch or replacing an existing US healthcare payment processor, here's a roadmap that surfaces the gaps before contracts are signed rather than after go-live.

Weeks 1-2: scope the data flow. Map every system that touches PHI and every system that touches cardholder data. Identify the intersections — the systems that touch both. List the vendors behind each system. The output is a data-flow diagram your privacy officer can defend.

Weeks 3-4: define the RFP. Build the question set from the RFP checklist above (BAA willingness, breach SLA, subprocessor list, data-flow diagram, SOC 2, PCI AOC, breach history, access controls, audit logging, exit terms, references, incident response). Add the must-haves specific to your environment — EDI X12 support if you're a healthcare payer, FedNow if you're sending high-value payouts, specific telephony platform integration if you're tied into one.

Weeks 5-6: shortlist and security review. Get the RFP responses, score them, shortlist 3-5 vendors. Request the security packet under NDA from each: SOC 2 Type II, PCI AOC, sample BAA, subprocessor list, pen test summary. Have your security team review the packets, not just your procurement team.

Weeks 7-8: BAA redline. Get the BAA template from each shortlisted vendor. Redline against the must-haves above (indemnification, breach SLA, subprocessor flow-down, audit rights, termination terms). Note where each vendor will and won't move. This is where you find out which vendors actually understand HIPAA and which ones are checking a box.

Weeks 9-10: technical proof. For the leading vendor, run a technical proof in your environment with synthetic data. Verify the data-flow claims hold up. Watch the call recordings to confirm card data is actually absent. Verify the audit logs capture what they're supposed to.

Weeks 11-12: contract, BAA, and go-live planning. Sign the underlying services agreement and the BAA. Document the data-flow diagram as part of your security risk analysis. Build the production deployment plan with rollback criteria. Run a tabletop exercise on the incident response plan with the new vendor in scope.

This is more work than "call the vendor with the loudest marketing," but every day spent in vendor selection saves multiples in remediation cost if the wrong vendor lands in your environment.

If you want to walk through your specific call flow and figure out where the BAAs need to land, have a quick chat with our New York team — 15 minutes is usually enough to spot the gaps.