How to keep a card on file without the legal gray area

Keeping a customer’s card on file is normal, common, and permitted. The gray area isn’t the storing — it’s the missing record. The card networks ask you to disclose how the stored card will be used, get the customer’s agreement before you store it, keep that agreement, tell them about the charges, and give them a way to cancel. Capture those five things once, in writing, and the anxiety goes away permanently.

Almost nobody searches for this because they want to read about compliance. They search for it because they’re sitting on a customer’s card number they were handed six months ago, there’s an invoice sitting unpaid, and they don’t know whether running it makes them organized or makes them a problem. Contractor forums are full of the same question in different words: can I charge this without asking again?

The question underneath the question

Two owners with the same stored card are in completely different positions, and the difference has nothing to do with the card.

The first one got the card over the phone, wrote it on the work order, and has been charging it every month since. It works fine. It will keep working fine right up until one customer looks at a statement, doesn’t recognize the line, and calls their bank instead of calling you.

The second one had the customer sign something once that said, in plain language, what would be stored, what would be charged, when, and how to stop it. Same card. Same charges. But when the dispute lands, one of them has a document and one of them has a memory.

What the card networks actually ask for

Visa’s stored credential framework, which the other networks broadly mirror, sets out what a merchant has to do before and after storing a customer’s payment credential. Processors publish their own summaries of it; the requirements land in five places:

• Disclose how the stored card will be used. Not “we keep cards on file” — what you will charge it for.
• Get consent to store it, before you store it. The agreement comes first, not after the first charge goes through.
• Keep the agreement. It has to survive for as long as the consent does, and be producible on request.
• Notify them of upcoming charges, rather than letting a stored card become silent.
• Give them a way to cancel. A recurring arrangement the customer can’t exit is the one that generates complaints.

There’s also a plumbing requirement your processor handles rather than you: the transaction itself has to carry indicators saying whether the customer or the merchant initiated it, and whether it’s a one-time or scheduled charge. If you’re on a modern gateway, that happens without you thinking about it. It’s worth one question to your processor anyway.

This is a process guide, not legal advice. Network rules change, ACH rules differ from card rules, and some states add their own requirements on top. Confirm the specifics with your processor and, for anything you’re unsure of, your attorney.

The gray area is a dispute, not a courtroom

The fear people carry around this is vague and slightly legal-sounding. The actual risk is much more ordinary, and much more likely: a chargeback.

A customer sees a charge they don’t recognize — maybe genuinely, maybe because the bookkeeper who approved the work left in March — and disputes it with their bank. You get a notice and a short window to respond. What the bank wants is documentation: proof the customer agreed to stored-card billing, the invoice for that specific charge, the receipt you sent, and when it went out.

If you have those four, the response takes ten minutes and you attach files. If you don’t, you’re writing a paragraph explaining that you’re pretty sure they said it was fine. That’s the whole gray area. It isn’t a lawsuit. It’s an evidence problem that shows up on a deadline.

What your authorization needs to say

Short is fine. A paragraph does the job as long as it answers the questions a disputing bank would ask:

1. What’s being stored — card or bank account, and the last four digits so the customer can match it to their own statement.
2. What it will be charged for — this recurring service, invoices under this agreement, the balance of an approved estimate. Be specific enough that a stranger could tell whether a given charge is covered.
3. How much, or how the amount is determined — a fixed monthly figure, or “the amount of each invoice issued under this agreement.” Variable is allowed; unstated isn’t.
4. When it gets charged — on the invoice due date, on the first of the month, on completion. A date the customer can anticipate.
5. How they cancel — one sentence naming the actual method, whether that’s a portal toggle, an email address, or a phone number.
6. That they’ll get a receipt for every charge. This is the line that prevents most disputes from ever starting, because the customer sees the charge from you before they see it from their bank.

Where the record should live

The best place for this paragraph is inside a document the customer already has to sign. Most service businesses are already sending an estimate or a service agreement and waiting on approval before work starts. Putting the card-on-file terms in that same document means one signature, one timestamp, one file — instead of a second form nobody chases.

Two things make that signature worth something later. First, the customer has to have produced it themselves: a link sent to their own email, a signature they drew or typed, a consent box they ticked, with the time and the IP address recorded alongside. Second, the signed copy has to be retrievable years later, by both of you, without depending on someone’s inbox.

And the card number itself should never be the thing you’re storing. It belongs in the gateway’s vault, which hands your software back a token, a brand, and the last four digits. A card number written on a work order, saved in a spreadsheet, or sitting in an email thread is a liability with no upside — you can’t charge it any faster than a token, and you own the consequences if it leaks.

The customers whose cards you already have

This is the part that stops people, and it has a boring answer: you re-paper them once. You can’t retroactively manufacture consent you never captured, and you shouldn’t try.

1. Write the paragraph once. Six sentences covering the list above. It’s the only writing in this whole exercise.
2. Send it to your existing card-on-file customers as a one-time confirmation. Frame it as what it is: “we’re tightening up how we handle this, here’s exactly what we charge and how you stop it.” Almost nobody objects. The ones who do were going to be a dispute eventually.
3. Have them re-enter the card themselves in the portal, rather than you keying in the number you already had. It takes the raw number out of your possession and puts the entry in their hands.
4. Put the paragraph in the estimate template so every customer from here forward is handled at signature and you never do this migration again.

An afternoon, once. What you get back is that every future charge is one you can defend without thinking about it — and, less obviously, permission to actually use the thing. Most owners sitting on unauthorized stored cards aren’t over-charging them. They’re under-charging them, letting invoices age because running the card feels presumptuous. For what that hesitation costs, see what chasing late invoices actually costs you.

Where this fits with everything else

Authorization is the front door of the get-paid loop, not the whole thing. Once the card is stored properly, the next two questions are what charges it and what happens when it doesn’t. If you’re trying to do this inside QuickBooks, the documented Autopay limits are worth reading before you build a process around it. For the invoices that stay unpaid anyway, there’s reminders that chase late payers and leave good clients alone. And for what a stored card actually costs you every time it runs, what you actually pay to accept a card.

Common questions