Notes
Taking a deposit without building a second system.
Most shops end up with two payment systems that never agree and a monthly reconciliation done from memory. It starts with the first deposit taken the wrong way.
A deposit looks like the simplest transaction a shop takes. It is the one that most often turns into an argument, because the money arrives weeks before the work finishes and nearly nothing about what was agreed gets written down at the moment it is taken.
A hold and a charge are not the same thing
An authorisation reserves an amount against a card without moving it. A capture takes it. They are separate steps, and the gap between them is where most deposit problems live.
- An authorisation expires, typically within about a week, sometimes sooner. A hold placed when the car arrives will often be dead before the parts are.
- The customer sees a pending amount and frequently believes they have already been charged. When the capture lands later, they see it as a second charge. This is one of the most common disputes in a shop and it is caused entirely by not explaining the mechanism.
- Capturing more than was authorised can fail or be treated as a fresh transaction. If the job grew, that is a new authorisation, not a bigger capture.
So for a deposit on work that will take weeks, a hold is usually the wrong instrument. Charge the deposit properly, tell the customer it is a charge, and keep the card on file for the balance.
What to record at the moment you take it
Six weeks later, a dispute is decided almost entirely by what was captured at the time. Reconstructing it afterwards from memory and a paper invoice rarely works.
- What the deposit is against: the job, the vehicle, and the specific work or parts it covers.
- What the customer agreed to, in their words or by their acceptance, stored with a timestamp rather than remembered.
- Whether it is refundable, under what conditions, and what happens if parts have already been ordered. This single line prevents more arguments than everything else combined.
- Who took it and through which channel: counter, phone, or online. When the month does not reconcile, this is the field that tells you where to look.
Cards on file
Keeping a card for the balance is normal and it is allowed, and the rules around it are specific. The customer has to agree to it being stored and to being charged later, the card details themselves should never sit in your own systems or a drawer, and a later charge on a stored card is priced and treated differently from the original one.
The practical version: let the processor hold the card and give you a token, get the agreement in writing when the card is first taken, and never write a card number on a job sheet. A photograph of a card in a shop phone is the single worst payment habit in the trade and it is common.
Why the counter and the website stop agreeing
A shop that takes deposits at the counter, balances over the phone and the occasional payment online is running three paths into one business. Each one usually records the money somewhere slightly different, and none of them records it against the job in the same way.
| Path | Where the money is recorded | What is usually missing |
|---|---|---|
| Counter terminal | Processor batch, then a manual note on the job | Which job it belongs to, in any system that can be queried |
| Card taken over the phone | Same batch, priced higher, often no note at all | The acceptance, and frequently the address data that would have improved the rate |
| Online payment | The website, and the processor, and sometimes neither into the shop system | The link to the job number, which is the only thing that matters at month end |
Nobody sets out to build this. It accumulates, one reasonable decision at a time, and the cost shows up as somebody spending a day a month matching deposits to jobs by memory, and as the occasional payment that is never matched at all.
The fix is smaller than a rebuild
The useful move is almost never replacing the terminal or moving processor. It is making every path write the same job reference against the payment, so the shop system and the processor can be reconciled by matching rather than by remembering. That is usually a small integration and a change to how the counter takes a deposit, not a new system.
If you want the shape of what goes wrong on the online path specifically, the failure is almost always the webhook rather than the card form, and that is covered on the payments page.
Questions
Should I authorise or charge a deposit?
For work finishing within a few days, an authorisation is reasonable. For anything longer, charge it, because authorisations expire and the pending amount confuses customers into thinking they have been charged twice. Whichever you choose, say plainly which one it is at the time you take it.
Can I keep a customer’s card on file for the balance?
Yes, with their agreement, and the card itself must be stored by your processor as a token rather than by you. Get the agreement in writing when the card is first taken and record it against the job. Never keep the number itself, on paper, in a phone, or in a spreadsheet.
A customer says they never agreed to the deposit. What decides it?
Whatever was recorded at the time. The processor will ask for evidence on a short clock, and a timestamped acceptance describing what the deposit covered will usually settle it. An invoice produced afterwards generally will not, because it proves what you billed rather than what they agreed.
Do I need new software to fix reconciliation?
Usually not. The common fix is making each payment carry the job reference so the shop system and the processor can be matched automatically. That is normally a small integration against systems you already run rather than a replacement for either.