How to set up recurring billing
without storing credit cards

CARD VAULT GUIDES · UPDATED JULY 2026 · 8 MIN READ

Here is the sentence that surprises almost every business owner who hears it: you can charge your customers every month without keeping a single card number — and you never needed the CVV at all. This guide explains how that works under the actual card-network rules, and the workflow that makes "billing on file" both automatic and clean.

The three ways recurring billing usually goes wrong

Keeping the cards yourself. The membership list, the retainer clients, the monthly service accounts — each with a card number saved in a spreadsheet, a billing binder, or the notes field of your CRM, re-keyed into the terminal every month. It works right up until you read what PCI says about where those numbers live.

Re-asking every month. The "compliant" alternative many businesses fall back to: phone the customer each cycle, or email an invoice and hope. Now your renewal rate depends on catching people at their desk, your staff spends billing week chasing, and every call is another card number read out loud.

Marrying your processor. The slicker fix: your payment processor's own card-on-file feature. It genuinely solves storage — and quietly converts your customer list into their asset. The day you want to switch processors (rates change, service slips, they get acquired), you discover the stored cards don't come with you, and "switching" means asking every customer for their card again. Attrition does the rest.

How billing-on-file actually works under the rules

Stored-credential billing is explicitly supported. The card networks publish rules for exactly this arrangement. The requirements, in plain English: the customer agrees up front to what will be charged and when; the credential is stored in a PCI-compliant way; and the follow-on charges are marked for what they are. Do those three things and monthly billing is a first-class, sanctioned use of the system — not a workaround.

The first charge and the later charges are different animals. Networks distinguish customer-initiated transactions (CIT) — the customer is present and enters their card, establishing the relationship — from merchant-initiated transactions (MIT) — the charges you run later under that agreement, with the customer nowhere in sight. The first charge carries the CVV and the customer's participation; every charge after that references the stored credential instead. This is why…

…you never need to store the CVV. The security code exists to prove card possession at that first, customer-present moment. After authorization, PCI DSS requirement 3.3.1 forbids keeping it in any form — and the recurring model never asks you to, because merchant-initiated charges are processed without it. If your current process "needs" the CVV each month, that's the tell that it's re-keying card numbers rather than billing a stored credential.

The stored credential itself must be vaulted, not filed. Requirement 3.5.1 requires a stored account number to be rendered unreadable — strong cryptography with key management, truncation, hashing, or tokenization. In practice, for a small business, that means the card lives in a purpose-built vault and you hold a token: a reference that can charge that card through your gateway but is worthless anywhere else. Your systems, your CRM, your billing notes — all of them stay out of PCI scope because none of them ever contain a card number.

Consent is your operational armor. The networks require customer agreement to stored-credential billing; your future self will want it in writing. Capturing the customer's agreement to the terms alongside the card — what will be charged, how often, how to cancel — is both the rule-following move and the document you'll be glad exists the day a charge is questioned.

The workflow, end to end

1. Collect once, directly into the vault. Send the customer a secure card-request link (or take the card through hosted fields at signup). They enter it themselves; it lands in the vault; you receive a token and the last four digits. No number crosses your desk, your inbox, or your database.

2. Put the agreement on file with it. The customer's authorization — amount or basis, schedule, cancellation terms — is collected in the same motion and stored alongside the credential.

3. Charge the token on your schedule. Dues on the first, retainers quarterly, the monthly service run — charged from a virtual terminal by your staff or by API from your billing system. Each charge references the stored credential the way the networks expect.

4. Let expiry be a notification, not a decline. Cards expire on a schedule you can see. A proper vault surfaces expiring cards ahead of the billing run — console views and webhooks — so the fix is a secure update link sent this week, not a failed payment discovered next month.

Choosing where the credential lives

Everything above works with any compliant vault. The strategic question is who owns it:

Your processor's vault is the default path and solves the compliance problem. The trade-off is portability: the credentials are generally theirs, on their platform, and they stay behind if you leave. An independent vault holds the credential once and charges it through whichever gateway you configure — today's processor or next year's — so the customer list stays your asset. (That is what Card Vault is, so read this paragraph with that disclosure in mind.) Subscription-billing platforms add invoicing and retry logic on top; they're a fine layer, but ask the same question underneath: whose vault holds the cards, and what happens to them if you leave?

Frequently asked questions