1. What the software is actually responsible for
| The software decides | The processor decides |
|---|---|
| Whether one visit is one charge | Whether you are allowed to sell it at all |
| Whether a card on file works without re-entry | Your rate, per card type |
| Whether the terminal gets the total automatically | When the money lands |
| Whether a receipt goes out on its own | Chargeback handling |
| Whether a deposit is a link or an invoice | Whether you survive underwriting |
⚠️ Worth being plain about one thing, because software marketing blurs it: payouts, statements and dispute handling live in the processor’s portal, not in your EHR. A vendor showing you a beautiful payouts dashboard is showing you a copy of a screen you already have, and when the two disagree you will believe the processor. We do not build that, and we would rather say so.
2. One patient, one total, one receipt
The test is a visit with three different kinds of line on it. A consultation, a membership month, and a medication. Can the front desk take that as one payment, and does each line land where it should?
For a prescribing clinic this is not a nicety. Mainstream card processors prohibit prescription drug sales in their terms and enforce it retroactively, so the medication line has to settle on an underwritten rail while the rest can sit on an ordinary one. The patient should see one total; the routing is the software’s job and should not be anyone’s decision at the desk.
Ask the vendor to ring up that exact mixed basket on the call. If the answer is “you would take those as two separate payments”, that is a workflow your staff will perform several times a day forever.
3. Card on file, deposits, and the difference between a link and an invoice
A card on file is what makes everything else work — the membership that renews, the no-show fee you decided to charge, the refill the patient approved by message. The thing to check is whether saving a card requires a charge: some setups can only store a card by running one through, which means a dollar charged and refunded and a confusing line on the patient’s statement.
On deposits, the mechanism matters more than it sounds. A deposit should be a pay link, not an invoice. An invoice is a document that gets paid eventually and chased in between; a pay link either converts now or does not, which is exactly the behaviour a deposit needs to have. Clinics that send invoices for deposits end up chasing them, which defeats the point.
| Moment | What it should be | Why |
|---|---|---|
| Holding a new patient slot | A pay link, before the booking confirms | An unpaid deposit should not hold a slot |
| A membership renewal | Card on file, automatic | Nobody should be invoicing a subscription |
| A balance after a visit | Card on file or a link | The patient has already left |
| A refill the patient approved | Card on file | They approved it in the app; asking again loses them |
4. Receipts and superbills, which are not the same thing
A receipt proves a payment. A superbill is a document the patient submits to their own insurer for reimbursement — coded, dated, with the provider’s details on it. Cash-pay clinics need both, and plenty of software provides only the first.
Receipts should go out automatically rather than on request, and the setting should be opt-out rather than opt-in. The clinics that make them optional end up with staff remembering to send them, which means roughly half go out.
5. Where each system actually fits
Front-desk retail and service checkout — a cash drawer, barcode scanning, product sales alongside treatments. Zenoti, Boulevard, Vagaro and Mindbody sell into high-footfall operations and their checkout is built for that counter.
Aesthetics checkout with loyalty attached — packages drawn down, tox units tracked, rewards applied at the till. PatientNow, Pabau and Aesthetic Record sell into med spa work.
Coaching and programme billing — a recurring plan with little or no in-person transaction. Healthie and Practice Better.
Insurance-billed practices — if a meaningful share of revenue is a claim rather than a card, the claim is the centre of the system and you should buy accordingly.
A mixed basket with medication in it — one checkout where a consultation, a membership month and a prescription each settle where they are underwritten to settle, with a card on file and a terminal that gets the total sent to it. This is the case Aminova was built for.
Where we are the wrong choice: if you need a till with a cash drawer, if retail product sales are the main business, or if most of your revenue is billed to insurance. Those are real requirements and we do not pretend to meet them.
6. The counter, and the thing nobody checks
Ask whether the software can send the amount to the terminal. If it cannot, somebody keys the total into a card machine by hand at every card-present visit, and the reconciliation at the end of the day is a matching exercise rather than a report.
⚠️ And one warning worth more than it looks: a card reader is locked to the merchant account it was bought for. A terminal from one processor cannot be moved to another, whoever you switch to. Clinics plan a switch, budget for the software, and then discover they need new hardware. Ask before you buy a reader, and ask before you switch.
7. Frequently asked questions
Do you take a percentage of what we collect?
No. We charge a flat monthly fee for the software and nothing per transaction. The merchant account is yours, the agreement is between you and the processor, and funds settle to your bank without passing through us.
Can we keep the processor we already use?
Usually, for everything except medication. Mainstream processors prohibit prescription drug sales in their terms, so that line has to go somewhere underwritten for it — but the rest of your revenue can stay exactly where it is.
Where do we see payouts and chargebacks?
In your processor’s portal. We deliberately do not rebuild those screens: they belong to the merchant account, which is yours rather than ours, and a second copy that disagrees with the first helps nobody.
Can we store a card without charging it?
Yes. Saving a card should not require running a charge through it, and a dollar charged and refunded is a support call from the patient waiting to happen.
Does it work with our card terminal?
It depends on the terminal, and this is worth checking before you buy one. A reader is tied to the merchant account it was issued for, so the question is really which processor you are on. Ask us before you order hardware.