Large tickets deserve better than retail rates.
A practice that collects the patient's share on cards pays fees on some of the biggest tickets in local business. Set it up right and most of that cost shrinks a lot. Or it moves off your books.
Get a free rate analysis
What practices are up against
Big tickets, big fees
3% on a $1,200 treatment plan is real money. And it repeats all day. Practices feel card costs more than almost any other business.
Payment plans need structure
Caring for patients often means letting them pay in parts. That needs a card on file, a set schedule and clean reports.
Front desk isn't a bank
Your staff should not have to chase balances. They should not re-key cards or match up books by hand.
The program fit
Surcharging
Details →Patients pay by credit card far more than most. That makes the disclosed credit surcharge work well here. Credit only, capped, never on debit.
Interchange plus
Details →Would you rather eat the fee quietly? Pay true wholesale cost plus a small markup we agree on. Not a padded flat rate.
Where your patients' card data actually goes
A patient hands a card to your front desk. Here is what happens to that number.
On the setups we place for practices, the reader is part of a PCI-listed point-to-point encryption solution paired with tokenization. Listed means the whole deployment is validated, the device, the application, the key management and the decryption environment, not just the box on the counter. On those, a card that is tapped, dipped or swiped is encrypted inside the reader itself, so your computer, your practice management software and your network never see the number. What your system stores is a token, a stand-in only the processor can match back to a card. If someone walked off with your front desk PC, they would not get card numbers off it. They could still get whatever that machine is signed into, so the workstation, the logins and the saved tokens still need locking down like any other system holding patient payment records. That is a property of the specific reader and processor combination, not of card terminals generally, so it is worth asking any vendor to name theirs on the PCI list. We will tell you exactly which one yours is.
Keyed payments work differently, and any honest description has to say so. A card taken over the phone, or typed into a virtual terminal for a payment plan, is entered on a screen, so that screen is briefly in scope in a way a reader is not. What limits the exposure is where it is typed. Keyed into the processor's own hosted page, the number goes straight to their vault and is replaced by a token before anything lands in your software. Typed into a field your own system stores, it does not. That distinction is worth asking any vendor about directly, and we ask it for you.
Done this way, two things follow. Card numbers stay off your systems, which is what shrinks your yearly PCI paperwork. And card data stays out of the same place your patient records live.
One honest note, because this gets oversold. PCI and HIPAA are different rules covering different data, and the exemption people quote is narrower than the marketing suggests. Federal law puts a processor's own transaction handling outside HIPAA, so a processor that only moves card data is usually not your business associate. That exemption covers them, not you. A payment record your practice keeps because a named patient paid for treatment is still your data under your rules. And a vendor that goes further, handling patient balances, statements or reminders, is doing work on your behalf, so that one should sign a Business Associate Agreement.
We are a broker. We do not touch your patients' cards. We place the processor and the hardware, and we will show you in writing what each one does with card data.
Related payment options
- Ways to lower your processing fees
The programs that cut the biggest line on your statement.
- Surcharging for medical and dental offices
Patients pay by credit card far more than most. That makes the disclosed credit surcharge work well here. Credit only, capped, never on debit.
- See what our clients say
Real Seattle-Tacoma businesses, five stars.
- Clover for medical and dental offices
Easy checkout for the front desk. Keeps a card on file. Reports your bookkeeper will like.
- Get a free rate analysis
See your real numbers before you decide anything.
Fair questions
Should a medical office add a card surcharge?
It is common, and in Washington it is allowed under the card network rules. A compliant surcharge has several requirements, not just a couple: advance notice registered with the card networks, a cap (Visa 3%, Mastercard 4%, never above your actual cost of acceptance, whichever is lower), disclosure before payment, and its own itemized line on the receipt. Debit, HSA and FSA debit cards are never surcharged. Rules vary by state, so this is scoped to Washington; see our Washington surcharge rules for the full detail. We handle the network registration and the rest of the setup so it's done right.
Can payment plans run on their own?
Yes. Keep a card on file and charge it on a set schedule. Receipts and reports come with it. No chasing at the front desk.
Do you offer patient financing?
Yes. Financing programs let patients pay over time. The practice is paid in full up front.
How does this interact with HSA/FSA cards?
They run like any other card, and they are never surcharged. The terminal knows the difference, not your staff.
Is the card gear compliant for a clinic?
The card hardware is standard and PCI-compliant. We work with your practice software. We do not disturb it.
Is a patient's credit card number protected health information?
In your hands, usually treat it as though it is. A card number in the abstract is financial data, but the moment your practice holds one because a specific patient paid you for care, it is identifiable information about payment for that person's treatment, and that is squarely what HIPAA covers. It does not take a treatment note sitting beside it. The narrow exemption people quote applies to the bank or processor running the transaction, not to your own record of it. Practically, that means saved payment records belong under the same access controls, audit logging and retention rules as the rest of your patient data, and the safest version is not to hold the number at all. Keep it in the processor's vault and keep only a token in your system, and there is far less of it to protect in the first place.
Does my payment processor need to sign a Business Associate Agreement?
Usually not, if it only handles card data. Federal law puts a processor's own transaction handling outside HIPAA's reach. But the moment a vendor handles patient information on your behalf, a BAA is not optional, it is required. That covers patient statements, balance reminders by text, and accounts receivable work. If a vendor we place does any of that, we make sure the BAA is signed before it goes live.
Is there such a thing as HIPAA compliant payment processing?
Not as a certification. The federal government does not certify any company or product as HIPAA compliant, so treat that badge as marketing language. What you can actually verify is concrete: a processor's PCI DSS Level 1 service provider status, whether its encryption is PCI-validated point-to-point, and whether it will sign a BAA when the work calls for one.
What do encryption and tokenization actually do?
Encryption scrambles the card number inside the terminal at the moment of payment, so it travels as unreadable data. Tokenization replaces it with a substitute number for anything you keep on file, like a card saved for a payment plan. On a card tapped, dipped or swiped through a reader that is part of a PCI-listed P2PE solution, that combination keeps the real number off your front desk computer, out of your software and out of your backups. Two limits worth knowing. It depends on the entire deployment being a PCI-listed P2PE solution, device, application, keys and decryption together, not on the hardware merely looking modern or the reader alone appearing on a list. And a card read to you over the phone and keyed in is a different path, protected only if it is typed into the processor's own hosted page rather than a field your system stores.
Does this reduce what we have to do for PCI?
Usually it reduces the work, and we are not going to tell you which form to file, because that is genuinely not ours to say. Here is the honest shape of it. Card data encrypted inside a reader that is part of a PCI-listed P2PE solution and never reaching your systems takes that channel largely out of scope, and that is the part that does the work. But scope is per channel, not per business. If you also key cards for phone payments or a payment plan, that is a second channel and it is assessed on its own, which usually means a fuller questionnaire than the reader channel alone would need. Your acquirer decides which self-assessment applies to you. What we do is tell you exactly which solution you are on and what channels you are running, so that conversation takes ten minutes instead of a guess. Anyone selling you a short form sight unseen is guessing on your behalf.
See what your practice keeps.
One statement, 24 hours, your real number in plain English.