Why the framework exists
Until 2017, an issuer receiving a card-not-present charge had no reliable way to know whether the cardholder was present and typing, or whether a merchant was charging a card it had stored months ago. The two situations carry very different risk, and issuers responded by declining more card-not-present traffic across the board. Visa's Stored Credential Transaction Framework (2017) and Mastercard's Credential-on-File rules (2018) fixed this by requiring merchants to say, on every transaction, who initiated it and why, and to link each follow-on charge to the customer's original consent.
The payoff for a merchant that does it correctly:
- Higher approval rates. Issuers apply different risk models to a properly flagged merchant-initiated charge than to an anonymous card-not-present one, and several publish approval-rate lifts for compliant traffic.
- Correct interchange. Flagged recurring transactions qualify for their intended categories rather than falling to standard rates. See reading your merchant statement for what a downgrade costs.
- Fewer disputes. The framework's disclosure and receipt rules exist because "I didn't know I'd be charged" is the most common subscription chargeback.
- Cleaner declines. Issuers can respond to a merchant-initiated charge with codes that tell you the customer cancelled (R0, R1, Mastercard advice code 21) rather than a generic decline.
The vocabulary comes from the framework and is used throughout: a credential is a card number or the token that stands in for it; a cardholder-initiated transaction (CIT) is one where the customer actively participates; a merchant-initiated transaction (MIT) is one the business sends without the customer present, under an agreement the customer made earlier.
The transaction types
The framework divides stored-credential transactions into the initial storage and two families of follow-on charges. Each has its own indicator value, and using the right one is the whole job.
The initial transaction (always a CIT)
The customer is present, enters or selects the card, and agrees to have it stored and to the terms under which it will be charged. This transaction is flagged as the initial stored-credential transaction, and it can be a real purchase or a zero-dollar account verification if nothing is due yet. The authorization returns a transaction identifier that every later MIT must reference. Without a correctly flagged initial CIT, nothing that follows is compliant.
Cardholder-initiated with a stored credential
A returning customer chooses a saved card and clicks pay. The customer is present, so it is a CIT, but it uses a stored credential, so it carries the stored-credential indicator. This is what a "pay with card on file" button on a customer portal produces. It is not an MIT, and must not be flagged as one.
Merchant-initiated: standing instructions
Charges made under an agreement for future payments, at a schedule or on an event the customer agreed to in advance.
| Type | Definition | Examples |
|---|---|---|
| Recurring | Fixed or variable amount at fixed intervals, until cancelled | Subscriptions, memberships, monthly service plans |
| Installment | A defined total split into a set number of payments on a schedule, with an end date | A $2,400 job paid in six monthly charges; a financed premium |
| Unscheduled credential-on-file (UCOF) | A charge on an event rather than a schedule, for an amount not known in advance, that the customer agreed to be charged for | Usage-based billing; auto-reload when a balance runs low; charging the balance when a repair is complete; a hotel's post-checkout charge for the minibar |
Merchant-initiated: industry practice
Charges that follow a cardholder-initiated transaction as part of completing it, rather than under a standing agreement.
| Type | Definition | Examples |
|---|---|---|
| Incremental authorization | Adds to an existing authorization when the final amount grows | A hotel stay extended; a car rental with added days |
| Delayed charge | A charge after the original transaction for services or damages associated with it | Damage found after a rental return; a restaurant tip added later where allowed |
| Reauthorization | A new authorization when the original has expired or a split shipment ships later | An order shipped in two parts, the second after the first authorization expired |
| Resubmission | A retry of a charge that was declined when the goods or services had already been delivered | A transit fare that failed at the gate and is retried later; a subscription retried after an insufficient-funds decline |
| No-show | A charge for a reservation the customer did not use | A no-show fee under a disclosed cancellation policy |
The distinction between the two families matters because issuers treat standing-instruction MITs as agreed-to and industry-practice MITs as tied to a specific earlier purchase. A resubmission, for example, must reference the transaction that was declined, and Visa limits how many times a declined recurring charge may be resubmitted (see the retries section).
What each transaction must carry
Every gateway exposes the framework's fields under its own names, but the underlying data is the same across Visa and Mastercard. A compliant integration sends, on every stored-credential transaction:
| Field | Values | Notes |
|---|---|---|
| Initiator | Cardholder or merchant | Who is present. Gateways call it "initiated by", "customer or merchant initiated", or a POS environment code. |
| Stored-credential indicator | Initial storage, or subsequent use | Set to initial on the first CIT that stores the card (including zero-dollar verifications); to subsequent on everything after. |
| Transaction type / reason | Recurring, installment, unscheduled, incremental, delayed, reauthorization, resubmission, no-show | Only on MITs. Gateways may call it "billing method", "MIT reason" or "transaction category". |
| Original transaction ID | The network transaction identifier returned by the initial CIT (Visa: Transaction ID; Mastercard: Trace ID) | Required on every MIT. This is the link the issuer uses to confirm the customer's original consent. Store it with the token; if the gateway manages it for you, confirm that it does. |
| For installments | Total number of payments and the current payment number | Some regions also require the total amount and frequency. |
| For the initial CIT | Full cardholder verification: CVV, AVS, and 3-D Secure where used | The security code is used for the initial authorization and then must not be stored. MITs are sent without it, which is expected and does not hurt approval. |
Field names vary by gateway; the values map to the network indicators described here.
Three common integration mistakes: sending every follow-on charge as a plain card-not-present transaction with no indicator (the default in many older integrations); sending a card-on-file CIT as an MIT because the code path is "charge saved card"; and losing the original transaction ID when migrating tokens between gateways, which silently breaks the chain for every stored card. The third is a reason to store the ID in your own records, or in a provider-agnostic vault, rather than only in the gateway.
Consent and disclosure: what the customer must agree to
The framework requires that the cardholder agree, at the initial transaction, to the credential being stored and to the terms of future charges, and that the agreement be captured and retained. Both networks specify what the disclosure must contain, and both added subscription-specific rules in 2020 and after.
At the initial transaction
- A clear statement that the card will be stored and used for future charges, with the customer's explicit acceptance (a checkbox, a signature, a recorded yes). Storing a card silently after a one-off purchase is not consent.
- The amount or how it will be determined, the schedule or the triggering event, and for installments the total, the number of payments and the frequency.
- How the customer can cancel, and any notice period.
- For unscheduled charges, the circumstances under which they will be made.
- A confirmation sent to the customer (email or text) with the terms, and a receipt for each charge.
Subscription and trial rules
| Rule | Visa | Mastercard |
|---|---|---|
| Free or discounted trials converting to paid | Express consent at signup; a reminder at least 7 days before the trial ends with the amount and date of the first charge and how to cancel | Notification at least 7 days before the trial ends with the amount, date and cancellation instructions; a receipt after each charge |
| Cancellation | An easy online cancellation method, at least as simple as signup; a link in confirmations | Online cancellation method; confirmation of cancellation to the customer |
| Receipts | Confirmation email at enrolment; receipt for each charge with cancellation instructions | Receipt for each charge with the cancellation method |
| Changes to amount or schedule | Notice before the change, with the ability to cancel | Notice before the change |
| Statement descriptor | Trial-converted charges must be identifiable | A recognizable descriptor |
As published at the time of writing. Both networks have expanded subscription rules since 2020, including for negative-option billing; check your acquirer's current guidance.
These overlap with US consumer-protection law on negative-option and automatic-renewal billing, which several states and the FTC also regulate. The practical design that satisfies all of them: explicit checkbox consent with the terms next to it, a confirmation email, a reminder before any trial converts or any amount changes, a receipt for every charge, and a cancel button that works. Each of those is also a chargeback prevented; see chargebacks explained.
Storing a card without charging it
Often the customer wants to store a card before anything is owed: signing up for a plan that starts next month, adding a card to an account, or agreeing to be charged when a job is done. The framework handles this with a zero-dollar account verification: an authorization for $0.00 with full verification data (CVV, AVS, optionally 3-D Secure), flagged as the initial stored-credential transaction. The issuer confirms the card is valid and open, returns the transaction ID that later MITs will reference, and no charge appears for the customer.
Two cautions. A $1 authorization that is later voided is the old way of doing this and is discouraged: it leaves a visible pending charge, can attract a Misuse of Authorization fee, and some issuers decline it. Use a true zero-dollar verification, which every major gateway supports. And a verification is not consent: the disclosure and acceptance described above still have to happen at the same time.
Keeping stored cards alive: account updater and network tokens
A stored credential decays. Cards expire, are reissued after fraud, or change number when a bank is acquired. Roughly a fifth of stored cards change in some way each year, and every change produces a decline on the next MIT unless something updates the credential first.
- Card account updater services (Visa Account Updater, Mastercard Automatic Billing Updater, and the equivalents from Amex and Discover) let a merchant or its gateway submit stored cards in a batch and receive updated numbers and expiries, or a notice that the account was closed. Most gateways run this automatically for tokenized cards on a monthly or pre-billing cycle, for a per-update fee.
- Network tokens replace the card number in your vault with a token issued by the card network and bound to your merchant. When the card is reissued, the network updates the token itself, so the credential never goes stale. Issuers also tend to approve network-tokenized MITs at higher rates because the token is domain-restricted and cannot be replayed elsewhere.
Either one belongs in a recurring-billing setup. Neither replaces the framework flags: an updated card charged without the MIT indicators is still an unflagged transaction.
Retries, declines and what "stop" means
Merchant-initiated charges decline more often than cardholder-initiated ones, because the card had time to change and because the customer is not there to try another. The framework and the network retry rules together define what to do.
- Retries are resubmissions. A retry of a declined recurring or installment charge is itself an MIT of type resubmission, referencing the declined transaction. Send it with the flags, not as a fresh charge.
- The reattempt limits apply. Visa allows up to 15 reattempts in 30 days on a card for the same transaction and prohibits any reattempt of a hard decline; Mastercard limits attempts and charges for ignoring its advice codes. The full decline vocabulary is in decline codes explained.
- Some responses mean the agreement is over. Visa response codes R0 (stop payment order) and R1 (revocation of authorization), and Mastercard merchant advice code 21 (payment cancelled by the cardholder), mean the customer told their bank to end the arrangement. Cancel the plan, stop billing, and contact the customer; continuing is a violation and a guaranteed chargeback.
- Some responses mean "update the card". A 54 expired card, a 14 invalid number after a reissue, or Mastercard advice code 01 all mean the credential changed. Run the account updater or ask the customer; do not simply retry.
- Tell the customer on the first failure. A text or email with a link to update the card and pay recovers more than any retry schedule, and a customer who updates the card produces a fresh, properly flagged initial CIT.
Starting the chain from a text or email link
The framework is often described in e-commerce terms, but service businesses usually store cards after a phone call: a deposit taken, a plan agreed, a card to keep on file for the balance. The compliant way to do that is not to key the card into a virtual terminal (a MOTO transaction with the worst approval rates and interchange, and a PCI burden), but to send the customer a link. The customer enters the card on the hosted page, agrees to the stored-credential terms with a checkbox, and completes the deposit or a zero-dollar verification. That is a fully verified, cardholder-initiated, flagged initial transaction, and every installment or balance charge that follows can reference it. The consent record and the PCI scope both end up where they should. CIT vs MIT covers why the first transaction being customer-initiated matters so much to approval rates.
An implementation checklist
- Confirm your gateway supports the stored-credential fields (initiator, indicator, MIT type, original transaction ID) and find out what it names them.
- Every path that stores a card sends an initial CIT with full verification, the initial indicator, and captures the customer's explicit consent and the terms shown.
- Store the original transaction ID alongside the token, in your own records or a vault you control.
- Every scheduled charge sends initiator = merchant, indicator = subsequent, the right type (recurring, installment or unscheduled), and the original transaction ID. Installments also send the count and sequence.
- Every "pay with saved card" click by a customer sends initiator = cardholder, indicator = subsequent, and no MIT type.
- Retries are sent as resubmissions referencing the declined transaction, within the network limits.
- Stop-payment and revocation responses cancel the plan automatically and notify a person.
- Account updater or network tokens run before each billing cycle.
- Confirmation at enrolment, reminder before trial conversion or amount change, receipt per charge, and a working cancel button.
- Audit a sample of last month's transactions in the gateway: are the indicators present, and do the MITs reference a real initial transaction?
Where FloPay fits
FloPay's installment plans and subscriptions send every scheduled charge with the merchant-initiated indicators and the original transaction reference, retry soft declines as resubmissions within the network limits, and notify the customer with a link on the first failure. The initial transaction comes from a hosted checkout or a text-to-pay link where the customer agrees to the terms, and the credential lives in a provider-agnostic vault so the chain survives a change of gateway. Customer messaging handles the enrolment confirmations, pre-billing reminders and receipts the subscription rules require.
Recurring billing with the flags done right
FloPay installment plans and subscriptions send every charge with the stored-credential framework indicators, retry within the network rules, and keep the credential current. Ask us to audit how your current recurring charges are flagged.
See Installment Plans