Card-on-File Payments: Storing Cards and Keeping Them Current
Card on file payments need customer consent and correct transaction flags. Learn the network rules and how account updater cuts failed charges.
Photo: Pixabay
On this page 6 sections
Key takeaways
- Visa and Mastercard require consent and transaction flags. An account updater is a best practice, not a network rule.
- A signed authorization form covers only consent. Your system also has to mark the first charge as the one that stores the card.
- A new card number from an updater never overrides a cancellation, so end the agreement the day a customer cancels.
- Paper card forms at the front desk widen your PCI scope; replace them with vaulted capture.
Card-on-file payments let you charge a customer's saved card later: next month's gym dues, say, or the balance after a dog's dental cleaning. Card network rules ask for two things. You need documented consent before you store the card, and every later charge needs a flag that tells the issuer who started it. You'll also want a way to keep the stored card current when it expires or gets reissued. That part isn't a network requirement, but it decides whether your recurring revenue keeps arriving. If you skip the rules, expect more declines and chargebacks. If you skip the upkeep, good customers quietly drop off your books because their new card never reached your system.
What Counts as a Card-on-File Payment
A stored credential, or "credential on file" in network language, is any card number and expiration date you keep so you can use it for a future transaction. Where you saved it doesn't matter. A card saved to a POS customer profile counts. So does one sitting in a booking app or a gateway vault.
That covers more of your business than you might expect. A gym billing dues on the first of the month is using a stored card. A martial arts studio charging a belt-testing fee to the card it already holds is too. A veterinary clinic that keeps a card on file for a boarding stay qualifies, as does a salon that takes a card at booking so it can enforce its no-show policy. An online store's "save my card for next time" box also creates a stored credential, even when the customer is the one who clicks "pay" later.
Two cases fall outside the definition. One is a single sale where the card is never kept. The other is a payment where the customer presents the card fresh every time.
Credential-on-File Rules: Get Consent Before You Store
Visa and Mastercard both require merchants to get the cardholder's agreement before storing a credential and to explain how it will be used. These are network rules. They bind you through your merchant agreement, not through federal law. The exact wording differs by network and changes over time, so confirm the current version with your processor. In practice, the consent your customer sees should cover:
- How the stored card will be used (recurring dues, installments, or charges as needed)
- The amount, or how the amount will be determined if it varies
- When or how often charges will happen
- How to cancel or change the arrangement
- How long the agreement lasts, if it has an end date
Keep a record of that consent and send the customer a confirmation. If the terms change later, such as a dues increase or a switch from monthly to annual billing, tell the customer before the new charges start.
Many merchants assume a signed "card authorization form" settles everything. It only covers consent. The networks also expect the first transaction to be marked as the one that stores the credential, and every later transaction to carry the right label. Your gateway or POS usually handles that marking, but only if it's configured for stored credentials and your staff charge through the saved-card workflow instead of keying the number in fresh each time.
Subscription and membership businesses face a second layer: state law. Many states have automatic renewal statutes with their own disclosure and cancellation requirements, which our guide to state automatic renewal laws covers. Treat that as general information and have a qualified attorney review your terms.
Customer-Initiated vs. Merchant-Initiated Transactions
Every transaction on a stored card falls into one of two buckets, and the label travels with the authorization request to the card issuer.
Customer-initiated transactions (CIT) happen when the cardholder is present and actively choosing to pay. A member buying a smoothie at the front desk with the card on their profile is one example. An online shopper picking a saved card at checkout is another. Because the customer is in the loop, the issuer can apply normal authentication.
Merchant-initiated transactions (MIT) happen when you start the charge without the customer taking part, based on the agreement they already gave you. The networks sort MITs into types, broadly:
- Recurring: charges at fixed intervals, like monthly gym dues or an annual pet wellness plan
- Installment: a set purchase split into a fixed number of payments, such as a spa package paid over four months
- Unscheduled: charges at irregular times or for variable amounts under an agreed policy. A vet clinic might charge the card when a prescription refill ships, and a salon might apply the no-show fee a client accepted at booking.
- Industry-specific: some categories, lodging among them, have their own MIT types for incremental charges and no-shows
The label matters because issuers approve MITs more readily when they can see that the charge ties back to an earlier, consented transaction. A correctly flagged MIT typically carries a reference to the original transaction, which tells the issuer the cardholder already set this up. A recurring charge sent as if it were a fresh card-present sale can trigger declines, and it leaves you with weaker evidence if the customer disputes it. Ask your processor which stored-credential types your gateway or POS supports. Then check that the no-show fees you charge match the policy the customer actually accepted. Membership businesses can go further with our piece on gym membership billing that survives chargebacks.
How a Card Account Updater Prevents Failed Charges
Stored cards go stale. Cards expire, and issuers reissue them after a breach or a lost-card report. When that happens, the card on file stops working, and your next recurring charge declines even though the customer still wants to pay you.
A card account updater fixes much of this. Participating issuers report new card numbers and expiration dates to the networks. Your processor or gateway checks your stored cards against that data, either in scheduled batches before a billing run or in real time when you attempt a charge. The response usually takes one of a few forms: a new expiration date, a new card number, a notice that the account is closed, or a flag telling you to contact the cardholder.
The service has limits. Not every issuer participates, and coverage varies by card brand. American Express runs its own program separate from Visa and Mastercard. Processors price the service differently, often per successful update. Network tokenization attacks the same problem from another angle: the network issues a token that stays valid when the underlying card changes. Our article on network tokenization and fewer failed renewals explains how the two compare.
A Worked Example for a Membership Studio
The numbers below are illustrative, not industry averages. Picture a studio with 600 members on monthly dues. In a given month, 12 of their stored cards expire or get reissued.
- No updater: all 12 charges decline. Suppose follow-up emails and texts get half of those members to send new card details. Six members go unbilled that month, and some of them never come back.
- Updater turned on: it returns new details for 10 of the 12 cards before billing runs. Two charges decline, follow-up recovers one, and a single member goes unbilled.
Under these assumptions, the updater turns six missed payments into one. Multiply those five saved payments by your monthly dues, then compare the result with what your processor would charge for the updates it made. If the per-update fee is small relative to your monthly charge, the updater can easily pay for itself. The members it keeps from drifting away count too, even though they don't show up in a one-month calculation.
How to Store a Customer Credit Card Without Widening PCI Scope
The safest way to store a customer credit card is to never hold the number yourself. Use your gateway's or POS's vault, which replaces the card number with a token that's useless to a thief while the provider holds the actual card data. Compared with keeping card data on your own systems, that approach usually shrinks your PCI DSS obligations considerably. Our explainer on how tokenization cuts PCI scope covers the mechanics, and our guide to storing a card on file safely and legally goes through setup step by step.
Some habits create real exposure:
- Writing card numbers on paper intake forms kept in a binder at the front desk
- Typing card details into appointment notes or client profiles
- Keeping the card security code after the payment is authorized, which PCI DSS prohibits
- Emailing or texting card numbers between staff
Vet clinics and salons are especially prone to the paper-form habit, because cards get collected at check-in or when a client books. Replace the form with tokenized capture. Run the card on a terminal at check-in, or have staff enter it once through a virtual terminal that saves it straight to the vault. Then shred the old forms. For online and recurring billing, a payment gateway with a built-in customer vault handles both the storage and the stored-credential flags.
Handling Expired Cards and Cancellations
When a charge on a stored card declines, read the decline reason before you retry. An "expired card" decline or an updater "contact cardholder" response means you need new details, so send the customer a secure update link. A closed-account response means you should stop billing that card. Insufficient funds may clear on a later attempt.
Both networks restrict repeated retries on declines that mean "do not try again" and can assess fees for excessive attempts, so ask your processor how those rules apply to your account. Build your retry logic around the codes, as laid out in our guide to credit card decline codes and what to do about each, and pair it with a sensible dunning sequence for failed subscription payments.
Cancellations need just as much care. When a customer cancels, end the MIT agreement in your system that day. Disable or delete the stored credential if you have no other agreed use for it, and send a cancellation confirmation. An account updater doesn't give you permission to keep billing. If a cancelled member's card gets reissued and your system silently picks up the new number and charges it, expect a chargeback. File the original consent record alongside the cancellation record, because together they're your evidence if a charge is ever disputed.
Your most useful move this week is a short audit. List every place your business stores cards today, including the paper ones. Then ask your processor two questions: Are your stored-credential transactions flagged correctly, and is an account updater turned on? If you'd like a second set of eyes on your recurring billing setup, request a free quote from MannyPay, and a specialist will respond within one business day.
This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.
