Call 866-305-6454 to review card-on-file payment processing, recurring billing, gateway tokenization, and merchant account underwriting.
Card-on-file payments let a business save a customer’s payment credential and use it again later. They sit behind subscriptions, membership dues, one-click checkout, invoice autopay, and top-up balances. Card networks treat these payments as a defined framework, and the way a merchant labels each transaction affects authorization handling, dispute exposure, and customer trust.
This article explains the stored credential vocabulary, the consent and disclosure expectations, what PCI guidance says about card verification codes, and the operational records that support the model. It is descriptive and does not recommend a particular setup.
What a stored credential transaction is
Visa’s developer documentation describes credentialed transactions, also called credentials-on-file or card-on-file transactions, as “payments that either store a customer’s payment credentials for future use or use previously stored credentials to complete a transaction” (Visa Acceptance developer documentation).
The framework separates two kinds of payment events:
- Customer-initiated transactions (CIT). The customer is actively present, for example by checking out and choosing to save a card.
- Merchant-initiated transactions (MIT). According to the same documentation, a MIT “is processed without the customer’s active involvement.”
The first time a credential is saved, the transaction is an initial one. Later uses of that credential are subsequent transactions, and they are generally linked back to the earlier authorization.
Customer-initiated versus merchant-initiated use
The distinction matters because the customer’s role changes how the payment is described to the network and, later, how a dispute is read.
Customer-initiated stored credential use
A returning customer who selects a saved card at checkout is initiating the payment. The credential is stored, but the customer is present and confirms the purchase. Many merchants treat this as an ordinary online checkout that happens to use a token instead of a typed card number.
Merchant-initiated use
A merchant-initiated payment occurs under a prior agreement without the customer taking an action at that moment. Visa Acceptance support materials list several merchant-initiated scenarios (Visa Acceptance: Merchant-Initiated Transactions and Stored Credentials):
- Recurring. Fixed-amount payments processed at fixed, regular intervals.
- Installment. A single purchase billed in multiple transactions over a period.
- Unscheduled card-on-file. Variable-amount or variable-timing charges, such as an automatic balance top-up.
- Resubmission. A previously declined authorization reprocessed after the goods or services were delivered.
- Delayed charges. A supplemental account charge processed after the original services.
- Reauthorization. Situations such as split shipments or extended fulfillment.
- No-show charge. A reservation-related penalty charge.
Each category is identified differently in the authorization message, and the specific indicator or reason code depends on the gateway and API a merchant uses. A merchant’s gateway documentation is the practical reference for how those indicators are submitted.
Consent and disclosure
The Visa Acceptance documentation says merchants offering stored credentials must obtain the customer’s consent to store the credentials and disclose to cardholders how those credentials will be used. The support materials likewise describe cardholder consent to store card details on file and marking of all transactions based on credentials on file.
Consumer protection law adds a separate layer for online recurring offers. The Federal Trade Commission’s enforcement policy statement on negative option marketing summarizes the Restore Online Shoppers’ Confidence Act (ROSCA) as requiring sellers to clearly and conspicuously disclose all material terms before obtaining billing information, to obtain the consumer’s express informed consent before charging the account, and to provide simple mechanisms for the consumer to stop recurring charges (FTC Enforcement Policy Statement Regarding Negative Option Marketing).
The card network framework and ROSCA address different questions. One concerns how a payment is labeled and authorized. The other concerns what the customer was told and agreed to. Merchants may need to consider both, and the exact obligations depend on the business, the offer, and the jurisdiction.
What PCI guidance says about the card verification code
A frequent point of confusion is whether a saved card includes the three- or four-digit verification code. The PCI Security Standards Council answers this in an FAQ on card-on-file and recurring transactions: “These values are not needed for card-on-file or recurring transactions, and storage for these purposes is prohibited under PCI DSS” (PCI SSC FAQ). The FAQ also states that the codes must be completely removed from the entity’s systems and that the prohibition applies regardless of customer permission to retain them. The FAQ cites an earlier numbering of the requirement, so a merchant reviewing the current standard should check the PCI DSS version it is assessed against.
In practice, many merchants use a gateway token for the stored credential so the underlying card number does not sit in their own database. Whether this reduces the scope of a merchant’s PCI assessment depends on the integration and the assessor’s view, and it should be confirmed with a qualified security assessor or the acquirer.
Why the original transaction identifier matters
Visa Acceptance documentation tells merchants to store and submit the original transaction identifier or network transaction identifier tied to each billing agreement, rather than relying only on values held in a token management service. That identifier is how a later merchant-initiated payment is linked to the first authorized, consented transaction.
Operationally, this means a billing system may need to keep more than the token:
- The token or credential reference.
- The network transaction identifier from the initial authorization.
- The date and wording of the customer’s consent.
- The billing agreement terms shown at sign-up.
- The type of merchant-initiated payment each subsequent charge represents.
Where disputes and declines tend to arise
Without citing any specific rate, several recurring friction points can be described qualitatively.
- Unrecognized charges. A customer who does not recall agreeing to future billing may contact the issuer instead of the merchant.
- Missing or mislabeled indicators. A subsequent charge submitted as if it were a fresh customer-present sale may be handled differently by the issuer.
- Changed terms. A price or frequency change without notice can undermine the original agreement.
- Cancellation friction. If stopping the charges is difficult, a dispute may become the customer’s easiest path.
- Credential changes. An expired or replaced card can cause declines unless the merchant uses an account updater service or asks the customer for new details.
Each of these points to records and communication rather than to a single technical setting. Evidence of consent, a clear descriptor, and reminders before renewals are commonly discussed measures, and their usefulness varies by business model.
Considerations for different business models
Subscription and membership billers
Fixed schedules usually map to the recurring category. Trial conversions, plan changes, and renewal notices raise disclosure questions.
Usage-based and top-up billers
Variable amounts and timing usually fall under unscheduled card-on-file. The agreement may need to explain what triggers a charge and how the amount is determined.
Hospitality and travel
Delayed charges and no-show charges are called out as separate categories. The reservation terms and any cancellation policy become part of the supporting record.
B2B invoicing
Businesses that save a corporate card for invoice autopay face the same labeling questions, and may also weigh ACH debit authorization as an alternative path with its own rules.
A review checklist
The following questions can help a team examine an existing card-on-file program:
- Does each saved credential have a recorded, dated consent?
- Are initial and subsequent transactions flagged the way the gateway documentation describes?
- Is the network transaction identifier from the first authorization retained and reused?
- Is the card verification code excluded from storage after authorization?
- Do disclosures cover amount, timing, and how to cancel?
- Are renewal and price-change notices sent and logged?
- Is there a process for expired cards and declined merchant-initiated payments?
- Do support staff know how to find consent evidence quickly?
Card-on-file payments are a long-running agreement between a merchant and a customer, not just a stored number. The consent record, transaction labeling, and card data handling each play a part, and the details vary by network, acquirer, and gateway.
Call 866-305-6454 now to review card-on-file processing, recurring billing workflows, gateway integration, and merchant account options.
Disclaimer: This article is for informational purposes only and is not financial, legal, or tax advice. Card network rules, PCI requirements, and consumer protection laws change and apply differently to each business. Consult qualified professionals, your acquirer, and legal counsel before making decisions.
Sources
Need Help With Payment Processing?
Talk to our team about rates, gateways, and solutions for your business.
Get a Free Quote →