On this page
Card on file means your payment processor stores the customer's card and gives your system a token to charge later. Autopay is the rule that charges it, for example after each completed visit. It works when the customer opted in to clear terms (what gets charged, on what schedule, how each amount is calculated, and the way to cancel), when you never store raw card numbers yourself, and when every charge is followed by a receipt.
Key takeaways
- Your processor stores the card; your CRM keeps only a token, the brand and the last four digits.
- Customers must opt in to terms that say what, when and how much you'll charge, and how to stop it.
- Bank account debits from consumers need a signed or similarly authenticated authorization and a copy for the customer.
- Card networks can update expired or replaced cards automatically, so autopay keeps working.
- Charge after the work is done, send a receipt every time, and warn customers before unusual charges.
What are card on file and autopay?
Card on file is a saved payment method. The customer enters their card once, the payment processor stores it, and your system keeps a reference (a token) it can use to charge that card later. Autopay is the rule that decides when the token gets charged: after every visit, on the first of each month, when an invoice is created, or when a deposit is due.
For one-off jobs, a pay link on the invoice is usually enough; cards, bank payments and fees are explained in online payments for contractors. Card on file earns its keep with repeat work. A lawn company with weekly customers, a pool service, a cleaning company or a pet waste business might send hundreds of small invoices a month. Chasing each one by hand is a part-time job. With autopay, the visit is marked done and the money arrives.
Where is the card actually stored?
With the processor, not with you. When a customer enters a card on a payment form provided by your processor, the card number goes straight to the processor. Your CRM gets back a token plus harmless details like the card brand, the last four digits and the expiry date.
This matters because of PCI DSS, the card industry's security standard. Stripe's integration security guide says PCI DSS applies to anyone who stores, processes or transmits card data, and that a business handling raw card data directly may face more than 300 security controls. Using the processor's own payment forms keeps card numbers off your servers and shrinks that burden. The same guide says the brand, last four digits and expiry date are not subject to PCI and can be stored.
Rules of thumb for your team:
- never write card numbers on paper, in notes fields, in texts or in email;
- if a customer reads a card over the phone, type it straight into the processor's form, never into a CRM notes field;
- let customers add or replace cards themselves through a secure page, such as a client portal.
What does the customer have to agree to?
Saving a card and charging it without the customer present needs their agreement up front. Stripe's documentation on saving payment methods says you are responsible for complying with laws and card network rules, that a saved method may only be used for what your terms describe, and that you should collect explicit consent, for example with a checkbox. For charges made while the customer isn't there, it says your terms should cover four things. In plain words:
- that the customer agrees you may charge them for the specified transactions;
- when and how often those charges will happen;
- how each amount is worked out;
- how cancellation works, if it is a subscription.
For a service business, that might read: "Keep this card on file and bill it when each visit is marked complete, for that visit's price plus any add-ons I approve. I can cancel autopay anytime from my account page or by calling." Put that next to an unchecked box. Then email a copy, and keep a record of when and where the customer agreed.
Are the rules different for bank accounts?
Yes. Recurring debits from a consumer's bank account fall under the Electronic Fund Transfer Act and its rule, Regulation E. Under 12 CFR 1005.10:
- preauthorized transfers from a consumer's account may be authorized only by a writing signed or similarly authenticated by the consumer, and the consumer must get a copy;
- when a recurring transfer will vary in amount from the previous one, the payee or the bank must send written notice of the amount and date at least 10 days before the transfer;
- a consumer can stop a preauthorized transfer by telling their bank at least three business days before it is scheduled.
Service amounts often vary (an extra service this month, a pro-rated first month), so plan how your system sends that notice. Processors that offer bank debits usually build the authorization into their checkout; read their documentation for what they handle and what is left to you. Commercial accounts follow different rules.
This is a general summary of federal rules and processor documentation. State auto-renewal and consumer protection laws can add requirements. Have your payment terms reviewed by an attorney.
When should autopay actually charge?
Match the charge to the promise you made. Common patterns:
| Pattern | Charge when | Fits |
|---|---|---|
| Per visit | The crew marks the visit complete | Weekly or biweekly service with prices that can change visit to visit |
| Monthly plan | A set day each month | Flat-rate plans that even out the seasons |
| On invoice | An invoice is issued, after a short delay | Mixed work for repeat customers |
| Deposit, then balance | At approval, then at completion | Projects with material costs |
A short delay between invoice and charge (say, a day) gives the customer a chance to question something before money moves, and gives your office a chance to catch mistakes. For anything unusual, such as a one-time add-on, a missed visit fee, or a price change, tell the customer before you charge. Our recurring billing guide covers price increases, pauses and failed payments in more depth.
If you add a card surcharge, the card network and state rules in our online payments guide apply. Never apply it to bank, cash or check payments.
What happens when a saved card expires?
Often, nothing you have to deal with. Stripe's card documentation says it works with the card networks to automatically try to update saved card details when a customer gets a replacement card, and that this is widely supported for cards issued in the United States. It also says there is no way to know in advance which cards will update. So you still need a path for the ones that don't: a failed-charge message with a link to replace the card, a retry, and a note on the customer record for the office.
Who keeps the saved cards if you change software?
This is the question to ask before you save a single card. If the processing account is in your company's name (for example, your own Stripe account connected to your CRM), the saved cards live in your account and stay with you when you change CRMs. If the processing account belongs to the software vendor, you may have to ask every autopay customer to enter their card again when you leave. Processors document ways to move saved card data between them; Stripe, for example, describes a card import process from a previous processor. Ask your current vendor in writing what they will release and how. For everything else that has to move, read how to switch CRMs without losing data.
What are the common autopay mistakes?
- Pre-checked consent boxes or terms buried in a long agreement.
- Charging without a receipt. A charge the customer doesn't recognize turns into a dispute.
- Charging before the work is confirmed done when your terms say "after each visit".
- Old cards on inactive customers. Remove or stop using payment methods for customers who have cancelled service.
- No owner for failed charges. Decide who in the office reviews failed and disputed charges each morning, and how fast they act.
- A statement descriptor nobody recognizes. Set the name on the customer's statement to the brand they know.
When is custom autopay worth building?
Most field-service software supports card on file. Custom makes sense when autopay must follow rules specific to your business: charging on visit completion from the route, different terms for different plans, a surcharge on credit cards only, or several companies each with its own processor account. For our own companies, the software we wrote saves cards through each company's own Stripe account and charges them by autopay rules tied to completed work. Our custom CRM service sets this up on an account in your name.
Frequently asked questions
Can I keep customers' card numbers in my CRM?
Avoid it. Let your processor store cards and keep only the token, brand, last four digits and expiry date. Handling raw card numbers brings much heavier PCI security obligations.
Do customers need to agree again for every charge?
Not if their original agreement clearly covered those charges: what they're for, when they happen and how the amount is set. Unusual charges outside those terms need fresh agreement.
What if an autopay charge fails?
Tell the customer right away with a link to update their card, retry on a set schedule, and flag the account for the office if retries fail.
Is bank account autopay cheaper than cards?
Usually, but it is slower to confirm and it falls under Regulation E for consumer accounts, including written authorization and notice rules for varying amounts.
Sources
- Save a customer's payment method without making a payment, Stripe Docs, 2026
- Integration security guide, Stripe Docs, 2026
- How cards work: automatic card updates, Stripe Docs, 2026
- Import payment method data, Stripe Docs, 2026
- 12 CFR § 1005.10, Preauthorized transfers (Regulation E), Legal Information Institute
General information for service-business owners, not legal, tax or financial advice. Rules vary by state; check with a qualified professional for your situation.