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 centre, 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 programme, 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, procedure 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 healthcare billing operations, telehealth contact centres, and revenue cycle management (RCM) teams in the UK and US that take card payments tied to patient accounts.

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.

A pure payment transaction — a card number flowing to a processor, an authorisation 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 credit card processing guide 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 a US-based 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. If you can, 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 defence 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. Our client Pinnacle Group moved from SAQ D to SAQ A and cut their PCI scope by 95% with the right architecture. We've written that case up under why SAQ A beats SAQ D for contact centres if you want the longer read.

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 programmes. 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 authorisation. 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 realising 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 tokenised 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 a HIPAA 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 centre, and file with HHS. 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 healthcare billing is still done over the phone. Patients call to query a bill, 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: Tokenisation 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 tokenise: the processor stores the card, hands you back a token, and your billing system stores only the token plus patient ID. Tokenisation 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 / direct debit 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. UK practices use direct debit (Bacs) for the same reason. Your processor should handle bank account capture securely, with the same pause-and-mask workflow on phone calls. Reading a bank account 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 in the US require a reasonable method to verify the account is legitimate — micro-deposits, instant verification via Plaid or similar, or a signed authorisation form. Bacs in the UK requires AUDDIS submission and Service User Number management. The processor should handle the heavy lifting on both, with the patient interaction happening over the same call.

Item 11: Recurring billing controls and patient consent records#

Payment plans are common in 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 authorisation in a form that survives a chargeback dispute.

Specifically: signed authorisation captured at time of consent (verbal recording is acceptable if the recording is retained and the patient is told they're being recorded); pre-debit notification 10 calendar days before the first charge under NACHA (or per direct debit rules in the UK); 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. For US practices, also confirm the processor complies with state-specific limitations on payment plan fees, surcharges, and convenience fees — these vary by state.

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

Telehealth providers regularly bill patients in different states or countries from where the clinician sits. The processor needs to handle the tax, currency, and regulatory mix without creating new HIPAA exposure. Multi-currency support, settlement to your bank account in the operating currency, FX handling that doesn't surprise the patient at the moment of payment, and clear receipts in the patient's language. For US practices treating UK patients (or vice versa), the processor needs to support both card schemes and both direct debit / ACH systems.

One particular item to watch: cross-border calls. If your call recording vendor stores recordings in a different country from where the patient lives, you've introduced cross-border PHI transfer. Under HIPAA that needs to be addressed in the BAA. Under UK GDPR, if you're treating UK patients, you need adequacy or appropriate safeguards. Cheap call recording vendors based in jurisdictions with no adequacy decision 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. We've covered the numbers in detail under HIPAA fines for payment processing breaches.

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 centre, credit monitoring), and regulatory penalties. 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 customers in healthcare 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 a 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. If you want to do the work yourself, the HIPAA and PCI combined compliance guide walks through the joint evidence pack you'll need either way.

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

A healthcare contact centre 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, never in the payment platform). They discuss the bill, the procedure, any questions about insurance, 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. Authorisation 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 authorisation to the acquirer, and returned a token plus an authorisation code. The token lives in the billing system tied to the patient ID. The PHI lives in the practice management system 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 healthcare billing reality#

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%.

Common pitfalls when buying#

The pattern we see often enough to call it out: 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 healthcare 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 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 productised the healthcare onboarding — a fixed BAA template, a standard scope-reduction architecture, and a support team that's seen healthcare 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; tokenisation for stored cards with network token support; ACH or direct debit for larger balances; recurring billing with documented patient consent; telehealth and cross-border 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 healthcare billing operations across the UK and US — we'd rather help you ask the right questions than sell you the wrong product.