HIPAA Payment Processor Checklist — What to Look For

Last updated: 29 May 2026

If you've been told to pick a "HIPAA payment processor" for your medical practice, hospital billing office, or telehealth contact center, the first thing to know is this: HHS doesn't certify payment processors against HIPAA. They certify nothing. There's no official list, no logo program, no "HIPAA-compliant" badge a payments vendor can earn by paying a fee. What you can do — and what your compliance officer actually needs you to do — is verify a specific set of capabilities, contracts, and controls before you let any vendor touch a payment that's tied to a patient.

We've sat in plenty of vendor evaluations where a payments salesperson waves a marketing PDF claiming "HIPAA-compliant payment processing" and the buyer signs without asking the obvious follow-up. Six months later the billing team is recording every patient call — diagnoses, CPT codes, the lot — onto the same audio file as the card capture, and the compliance officer is white. This checklist exists so you can ask the right questions in week one and avoid that conversation entirely. It's built for US healthcare billing operations, telehealth contact centers, and revenue cycle management (RCM) teams that take card payments tied to patient accounts.

This piece sits inside our HIPAA-compliant credit card processing guide — read that for the wider context on why the phrase itself is loaded.

Why "HIPAA payment processor" is the wrong search term#

Let's settle this first because it shapes everything else on the checklist. HIPAA's Privacy Rule and Security Rule apply to protected health information — demographics, diagnoses, treatment records, anything that ties a person's identity to their health status. The Payment Card Industry Data Security Standard (PCI DSS) applies to cardholder data — the PAN, expiry, CVV, and anything that travels with them on the way to the acquirer. These are different regulatory regimes, different auditors, different penalty regimes. OCR enforces HIPAA. The card brands and your acquirer enforce PCI DSS through your merchant agreement.

A pure payment transaction — a card number flowing to a processor, an authorization flowing back — isn't PHI on its own. The trouble starts the moment you tie that payment to a patient record, an appointment, a procedure, or any health context. Once the payment lives inside a system that also holds health data, or once your call recordings capture both card details and clinical conversation, your payment processor is touching PHI. That's the trigger for HIPAA, and that's why you need a Business Associate Agreement in place before money moves.

So the real question isn't "which HIPAA-compliant processor do I pick?" It's "which PCI-validated processor will sign a BAA, configure their platform to keep PHI out of card-handling workflows, and produce evidence for both my QSA and my HIPAA auditor when each shows up?" The 14 items below answer that question.

Item 1: A signed Business Associate Agreement — with the right entity#

If a processor won't sign a BAA, the conversation stops. Full stop. Under 45 CFR §164.504(e) you can't share PHI with a third party that handles it on your behalf unless they're contractually bound as a business associate. Even if the processor argues they only touch card data and never PHI, the integration almost always blurs that line — the patient ID lands in the invoice description, the amount is tied to a CPT code, the call recording captures the conversation. Treat the BAA as a precondition, not a nice-to-have.

Watch out for the bait-and-switch where the salesperson agrees to a BAA on the call, then sends you a generic SaaS terms document with a one-line "we'll comply with HIPAA" sentence buried in section 14. A real BAA names both parties, defines permitted uses and disclosures of PHI, sets breach notification timelines (usually 30 days, sometimes 60), commits the processor to safeguards, lists subcontractors, and gives you termination rights. If the BAA doesn't list the specific subcontractors who'll touch PHI — the call recording vendor, the gateway, the storage layer — you've got blind exposure.

One client we worked with last year discovered their payment processor had subcontracted call recording storage to an S3 bucket with no encryption at rest. The BAA had a clause about "reasonable safeguards" but didn't name the subcontractor or require encryption. When the practice's HIPAA auditor flagged it, they had no recourse — the contract didn't actually require what the salesperson had verbally promised. Read the BAA. Get your healthcare attorney to redline it.

Item 2: Independent PCI DSS validation (not self-attested)#

PCI DSS scope and validation are separate things. A processor can claim "PCI compliant" because they filled in their own SAQ D last year. What you want is a Level 1 Service Provider listed on the Visa and Mastercard registries, with a current Attestation of Compliance (AOC) signed by a Qualified Security Assessor (QSA) — not a self-assessment. Ask for the AOC. Read the date. Check the version (currently v4.0.1 with v4.0 controls fully in force from 31 March 2025).

The Visa Global Registry of Service Providers is public. So is Mastercard's. If your processor isn't on either, they're not a Level 1. That doesn't make them non-compliant — smaller volume providers can validate at Level 2 or 3 — but it does mean you need to look at the SAQ themselves, not just take their word for it. For high-volume healthcare billing operations we'd recommend Level 1 service providers across the board. The few dollars of premium isn't worth the audit defense risk.

For your own scope, the cheapest path is to choose a processor that lets you qualify for SAQ A instead of SAQ D. That means no PAN ever lands in your environment, ever — not in audio recordings, not in CRM notes, not in agent screens. Stripe, Authorize.Net, Chase Paymentech, and NMI all have BAA-eligible configurations with different scope footprints; verify the BAA terms and the SAQ qualification claim for each, because the marketing pages and the engineering reality don't always agree. Our client Pinnacle Group moved from SAQ D to SAQ A and cut their PCI scope by 95% with the right architecture.

Item 3: A real architecture for keeping PHI off payment recordings#

This is the item nobody asks about in vendor demos and the one that wrecks the most HIPAA programs. If you record patient billing calls — and most billing operations do — the recording will contain the entire conversation: patient name, date of birth, the procedure being paid for, sometimes the diagnosis. If your agent reads card numbers back to the patient on that recording, you've now got PCI cardholder data and PHI on the same audio file. Both auditors will have questions.

The architecture you want is one where the agent pauses the recording at the moment of card capture, the buyer types their card details directly into the keypad (or speaks them into a secure capture engine), the digits never travel through the agent's headset or the recorded audio, and the recording resumes after authorization. Paytia's DTMF masking and channel separation are the two technical patterns that achieve this. They're not interchangeable — DTMF masking works on a single-channel PSTN call, channel separation splits voice and card capture onto separate paths. Your processor needs to support one or both.

Verify this in the demo. Don't accept "yes, we can do that." Ask for a live test call where the salesperson hits the secure-capture button and you listen to the recording afterwards. The card digits should be silent or replaced with a uniform tone. If you can hear the DTMF beeps, the masking isn't working. If you can hear the patient speaking the card number, you've still got cardholder data on the recording and you've still got the patient's voice tied to their procedure — PHI plus PCI in one file.

Item 4: PHI segregation in payment metadata#

Most processors let you attach metadata to a transaction — a customer ID, an invoice number, a description field. Healthcare billing teams love this because it makes reconciliation easy. The risk is that staff naturally put the patient name, the appointment date, or the procedure description in those fields. The metadata then flows to the processor, gets stored on their side, syndicated to their reporting tools, sometimes shared with sub-processors for analytics. Now the processor holds PHI without realizing it.

Three controls fix this. First, define a metadata schema with your processor that names allowed fields and bans free-text. Patient ID gets a tokenized internal reference, not a name. Procedure gets a code, not a description. Second, get the processor to commit in the BAA that they treat all metadata as PHI by default — encryption at rest, access controls, retention limits. Third, run a quarterly review of the metadata being submitted to the processor by your team. We've seen billing managers add "patient with cancer" to the description field because it makes their internal reports easier to read. That's a HIPAA breach in waiting.

Item 5: Access controls and audit logging that survive an OCR review#

HIPAA Security Rule §164.312(a)(1) requires unique user identification, automatic logoff, and access controls. §164.312(b) requires audit logs of system activity. PCI DSS requirements 7 and 10 require essentially the same things on the card side. Your processor should give you a single set of controls that satisfies both, not two separate dashboards you have to reconcile.

Things to check in the platform: every agent has a named login (no shared credentials, no "reception desk" account); role-based permissions limit which agents can see which patient data; session timeouts are configurable and default to 15 minutes or less; audit logs capture every payment action, every PHI access, every configuration change; logs are retained for at least six years (the HIPAA minimum) and tamper-evident. Get the processor to show you a real log export, not a screenshot. If they can't produce one in 24 hours of asking, you'll never get one during an active breach investigation.

Item 6: Encryption at rest and in transit — for both card data and PHI#

The Security Rule's transmission security and storage safeguards (§164.312(e) and §164.312(a)(2)(iv)) require encryption when reasonable and appropriate. PCI DSS requires it without the conditional. The combined effect: encrypt everything, everywhere. Your processor should use TLS 1.2 minimum (1.3 preferred) for all data in transit, AES-256 for data at rest, and a key management process you can audit. Ask who holds the encryption keys — the processor, you, or a third-party KMS. If it's the processor and they get breached, your data is in the same pile as theirs.

This applies to call recordings too. If your processor records calls (or hands recordings off to a sub-processor), the recordings must be encrypted at rest and the keys must be managed under a documented process. "We use AWS S3 with default encryption" is the minimum, not a gold standard. Ask for the KMS architecture, the key rotation schedule, and the procedure for recovering or destroying keys.

Item 7: Breach notification timelines that match HIPAA's 60-day clock#

HIPAA's Breach Notification Rule (§§164.400–414) gives covered entities 60 calendar days from discovery of a breach to notify affected individuals and HHS. As the covered entity, you only get those 60 days from the moment your processor tells you. If their BAA gives them 30 days to notify you, you've got 30 days to investigate, prepare letters, set up a call center, and file with OCR. That's tight.

Push for notification within 5 business days of the processor discovering the incident, escalating to 24 hours for breaches affecting more than 500 records (which triggers HHS reporting in real time and media notification under §164.408). Ask what "discovery" means in their contract — is it the moment a sub-processor reports it to them, or the moment their security team confirms it? You want the earliest reasonable trigger. Push back on language that lets the processor take 60 days, because that puts you outside your own statutory window.

Item 8: Telephone payment workflows that aren't bolted on#

Most US healthcare billing is still done over the phone. Patients call to query an invoice, agents take a card payment over that same call, and the workflow needs to satisfy PCI DSS for the card capture and HIPAA for the conversation around it. A processor designed for ecommerce checkouts and bolted onto a phone workflow with a manual key-in screen isn't the right fit — it puts the card data into the agent's screen and almost always into the call recording.

Look for a processor whose telephone payment platform handles the whole pause-capture-resume flow inside one product, with the agent staying on the call, the buyer entering card details directly, and the recording being automatically masked. This is what Paytia does for healthcare clients — the agent never sees or hears the PAN, the recording never captures it, and the patient stays on the line so questions about their account get answered in real time. If a vendor proposes "transfer the patient to an IVR" as their PCI solution, they've solved the card problem and broken the patient experience.

Item 9: Tokenization for stored payment methods#

Recurring patient billing, payment plans, and saved cards for telehealth subscriptions all need stored payment credentials. The wrong way is to keep the PAN encrypted in your billing system — you're now in scope for PCI DSS storage, you're holding cardholder data alongside patient records, and you've doubled your breach exposure. The right way is to tokenize: the processor stores the card, hands you back a token, and your billing system stores only the token plus patient ID. Tokenization is the single biggest scope reducer for healthcare billing operations.

Check three things on tokens. First, the token is meaningless on its own — it can't be used by anyone except your merchant account, ideally only by your specific MID. Second, the processor offers network tokens from the card schemes, not just gateway tokens — network tokens auto-update when cards are reissued, which matters a lot for monthly billing. Third, the token vault is logically separate from any system holding PHI. You don't want one breach exposing both.

Item 10: Support for ACH for larger balances#

US healthcare balances over a few hundred dollars are often better paid by ACH than card — the processing fees are lower and patients on payment plans don't max out their card limits. Your processor should handle bank account capture securely, with the same pause-and-mask workflow on phone calls. Reading a bank account and routing number aloud onto a recorded call is the same problem as reading a card number aloud, just in a different regulatory bucket. Paytia covers this under bank account capture.

Ask about the verification process. NACHA rules require a reasonable method to verify the account is legitimate — micro-deposits, instant verification via Plaid or similar, or a signed authorization form. The processor should handle the heavy lifting, with the patient interaction happening over the same call. Confirm the processor supports same-day ACH for time-sensitive balances and that the NACHA WEB or TEL authorization model fits your call workflow.

Item 11: Recurring billing controls and patient consent records#

Payment plans are common in US healthcare — a $3,000 deductible split across 12 months, a self-pay procedure on a 6-month plan, a monthly telehealth subscription. The processor needs to manage the schedule, retry failed payments intelligently, send patients a clear pre-debit notice, and store the patient's authorization in a form that survives a chargeback dispute.

Specifically: signed authorization captured at time of consent (verbal recording is acceptable if the recording is retained and the patient is told they're being recorded — which also ties into TCPA call-recording rules for one-party and two-party consent states); pre-debit notification 10 calendar days before the first charge under NACHA WEB/TEL rules; easy cancellation that doesn't require the patient to call during business hours; clear receipts after every charge; soft-decline retries on a schedule that doesn't repeatedly hammer the patient's account and trigger overdraft fees. Confirm the processor complies with state-specific limitations on payment plan fees, surcharges, and convenience fees — these vary by state, with Colorado, Connecticut, Kansas, Maine, Massachusetts, and Oklahoma having specific restrictions worth checking.

Item 12: Telehealth-specific support (cross-state)#

Telehealth providers regularly bill patients in different states from where the clinician sits. The processor needs to handle the tax, regulatory, and state-by-state consent mix without creating new HIPAA exposure. Multi-state surcharge rules, state-level breach notification timelines, and state medical records privacy laws (California's CMIA, Texas's MRPA, New York's SHIELD Act) all stack on top of federal HIPAA. The processor should know which states it operates in and what each one adds.

One particular item to watch: call recording residency. If your call recording vendor stores recordings in a different state from where the patient lives, you've introduced a state-level consent question (one-party vs two-party consent states for call recording — California, Florida, Illinois, Massachusetts, Pennsylvania, and Washington all have two-party consent rules). Under HIPAA the residency question is less acute, but the state law on top matters. Cheap call recording vendors with no documented residency model will create headaches you don't need.

Item 13: Real penalty exposure documented in the contract#

If the processor causes a breach, who pays? HIPAA's civil monetary penalties under HITECH run from $137 per violation (corrected promptly, didn't know) up to $2.13 million per violation category per year (wilful neglect, uncorrected) as of the 2024 inflation adjustments. PCI DSS non-compliance fines from the card brands typically run $5,000–$100,000 per month plus liability for any breach costs.

The BAA should include indemnification language that makes the processor responsible for their portion of any fines, breach response costs (forensic investigation, notification letters, call center, credit monitoring), and regulatory penalties — including state-level penalties, which can stack on top of the federal HIPAA fine for the same incident. Pure liability caps at "fees paid in the prior 12 months" don't protect you when the breach response runs into seven figures. Push for uncapped liability on PHI breaches caused by the processor's negligence, or at minimum a cap that's meaningful relative to your annual revenue and the worst-case breach scenario.

Item 14: A QSA and a HIPAA auditor who actually use it day-to-day#

References from real US healthcare customers are worth more than vendor brochures. Ask for three references from healthcare billing operations of comparable size, and call them. Specific questions: how did the implementation go, how often does the processor produce evidence for HIPAA and PCI audits, has anyone ever filed an OCR breach notification involving the processor, how responsive is the support team when something breaks at 6pm on a Friday.

Ask the processor which QSA firm signs their AOC and which healthcare-experienced HIPAA consultancies refer them. A processor with no referrals from healthcare auditors is either new to the vertical or has a reputation problem in it. Neither is good.

What healthcare contact centers look like when this is done right#

A US healthcare contact center running on the right stack looks like this. The patient calls in to query an invoice. The agent pulls up the patient record (which lives in the practice management system or EHR, never in the payment platform). They discuss the bill, the procedure, any questions about insurance and the EOB, all on a recorded call. When the patient agrees to pay, the agent presses a single button. The recording pauses, the patient hears a prompt, they type their card details into their phone keypad. The agent sees only "capturing" on their screen, hears the prompt audio, and stays on the call. Authorization completes in seconds. The recording resumes. The agent confirms the payment, offers to email a receipt, and ends the call.

Behind the scenes: the PAN never entered the agent's environment, the recording, the practice management system, or any system that holds PHI. The processor handled the card capture, sent the authorization to the acquirer, and returned a token plus an authorization code. The token lives in the billing system tied to the patient ID. The PHI lives in the EHR tied to the patient ID. They share an ID but they don't share data. Both systems have audit logs, both have access controls, and the BAA covers the boundaries. Both auditors get clean evidence packs at renewal time.

That's the architecture worth paying for. Anything less and you're choosing between PCI scope creep, HIPAA exposure, or both.

Pricing models that match US healthcare billing reality#

US healthcare billing has its own economics. Average transaction sizes are higher than retail, patients pay in mixed methods (HSA cards, FSA cards, credit, debit, ACH, payment plans), and refund rates can be elevated when insurance adjustments come through after the fact. Processor pricing models that work for ecommerce often punish healthcare practices unfairly.

Look for: interchange-plus pricing (so you see the wholesale cost and the processor markup separately, no bundling); no surcharges for HSA / FSA cards (these are tied to specific BINs and some processors charge extra for them); flat refund handling that doesn't claw back the interchange fee on returns; transparent chargeback fees with a fair representment process. Bundled "qualified / mid-qualified / non-qualified" pricing is a red flag in healthcare — your transaction mix will land mostly in the non-qualified bucket and you'll pay 3.5%+ on transactions that should cost you 2%. Confirm the processor publishes interchange-plus and that the BAA-eligible plan doesn't carry a meaningful price premium over the standard ecommerce plan.

Common pitfalls when buying#

The pattern we see often enough to call it out: US practices pick a payment processor because they bundle it with their EHR or practice management software, never having looked at PCI scope, never having read a BAA, never having tested whether the recording captures card data. The bundle is convenient. The bundle is also where most of the avoidable HIPAA exposure in the industry lives.

If you're already in this position, you can fix it without ripping out the EHR — keep the EHR for clinical and scheduling, and add a separate PCI-validated payment processor that the EHR integrates with at the API layer. The EHR holds the patient record. The processor holds the payment token. They reference each other by ID but they don't share PHI or cardholder data. This is the architecture most large US health systems run; smaller practices can run it too with the right vendor.

The other pitfall: assuming "HIPAA-compliant hosting" means "HIPAA-compliant payment processing." A processor running on AWS HIPAA-eligible services is using infrastructure that can be HIPAA-compliant. That doesn't mean the processor's application, processes, and contracts are. Infrastructure is necessary, not sufficient. Always look at the AOC, the BAA, the SOC 2 Type II report, and the operational controls together.

How to run the actual vendor evaluation#

Run this as a structured RFP, not a series of demos. Send the 14 items above as questions and ask each vendor to respond in writing. Require references. Demand a live test call where you specifically watch the pause-and-mask flow and listen to the recording afterwards. Get your healthcare attorney to review the BAA before you sign. Get your QSA (or a contracted QSA) to review the AOC and validate the SAQ qualification claim.

Budget 4–6 weeks for the evaluation if you've never done this before. Budget 8–12 weeks if you're replacing an incumbent and need to migrate stored payment methods, recurring billing schedules, and reconciliation processes. Don't try to compress this into a two-week procurement — the cost of getting it wrong is years of compliance pain.

Where smaller practices get stuck#

Small and mid-size US practices often hit a particular wall: the BAA process is opaque, the legal review is expensive, and the bigger processors won't engage with a low-volume customer. That leaves practices choosing between an enterprise processor they can't afford the legal review for, and a budget option that hands them a generic SaaS contract with no real BAA. The way out is to pick a vendor that's productized the healthcare onboarding — a fixed BAA template, a standard scope-reduction architecture, and a support team that's seen OCR audits before. You shouldn't have to invent the wheel.

Another stuck point: agents who've been doing manual key-in for years and don't want to change. Telling a 20-year billing veteran they're now going to press a button and let the patient type their card details takes a real change-management effort. Plan for it. Run training, write a one-page agent script, and let the team listen to a few real recordings of the new workflow so they hear what it sounds like to the patient. The patient experience is actually better — most patients prefer typing the card details themselves over reading them aloud to a stranger — but agents need to see that before they believe it.

What changes under HIPAA enforcement in 2026#

HHS Office for Civil Rights has been ramping up enforcement against business associates directly since the HITECH amendments and the 2024 NPRM signalled tighter Security Rule requirements. Whether or not the final rule lands in 2026, the direction of travel is clear: more specific technical safeguards, less wiggle room on "addressable" controls, more required encryption, more required audit logging. Payment processors that already operate to a tighter standard — PCI DSS v4.0 already requires most of what the proposed HIPAA changes contain — won't need to scramble. Processors running on outdated controls will.

The practical takeaway: when you're shortlisting processors, ask how they're preparing for the proposed HIPAA Security Rule update. If they don't know what you're talking about, they're not paying attention. If they say "we're already at PCI DSS v4.0 and SOC 2 Type II — most of the changes are already baked in," that's the right answer. Processors who don't actively track their regulatory environment will be the ones who cause your next breach.

Quick reference: the 14 items as a scorecard#

If you want to run this as a checkbox exercise during procurement, the items are: signed BAA with named subcontractors; Level 1 PCI Service Provider with current AOC; pause-and-mask architecture for call recordings; PHI segregation in payment metadata; access controls and audit logs satisfying HIPAA §164.312; encryption at rest and in transit for cards and PHI; breach notification within 5 business days; telephone payment workflow built in, not bolted on; tokenization for stored cards with network token support; ACH for larger balances under NACHA WEB/TEL; recurring billing with documented patient consent; telehealth and cross-state support; uncapped liability for processor-caused PHI breaches; references and a QSA / HIPAA auditor referral network. Any vendor that scores below 12 out of 14 needs a serious conversation before you sign.

Next steps#

If you want to run this checklist against Paytia specifically, the fastest way is to walk through the platform with our team and see the pause-and-mask flow on a real test call. Book a live demo and we'll show you the agent view, the patient experience, and the recording afterwards. If you'd prefer to start with a written brief tailored to your billing operation, contact us and we'll come back with a scoping document covering BAA terms, PCI scope reduction, and pricing. The team has implemented this architecture for US healthcare billing operations — we'd rather help you ask the right questions than sell you the wrong product.

For the wider context on the topic, read our HIPAA-compliant credit card processing guide. For the joint evidence model when both auditors show up, see HIPAA + PCI combined compliance for healthcare contact centers. For the contract clause that gates the whole thing, see what is a BAA. For the financial exposure, see HIPAA fines for payment processing breaches.