Card-on-File and Tokenization for Recurring

A card-on-file transaction is any transaction that uses payment credentials a merchant stored from an earlier transaction. The first transaction is called the initial credential-on-file transaction, and it must be initiated by the cardholder and fully authenticated. Every later transaction is a merchant initiated transaction that references the first one. The card schemes require the merchant to send specific indicators with each transaction, including a flag that says the credential is stored, a transaction identifier that links back to the original payment, and the type of transaction, such as recurring, instalment, or unscheduled. If these indicators are missing or wrong, the issuer may treat the payment as a new cardholder transaction and decline it. Tokenization replaces the real card number with a surrogate value called a token, and it is the standard way to store credentials safely. There are two main kinds of token. A gateway token is issued by the payment service provider and only works with that provider. A network token is issued by Visa or Mastercard themselves and works across the whole payment network. Network tokens are more powerful because the card scheme updates them automatically when the underlying card changes, and issuers trust them more, which leads to higher authorisation rates. The BA should recommend network tokens wherever the gateway supports them, and document the token lifecycle including provisioning, suspension, and deletion. The credential-on-file rules from Visa and Mastercard are detailed, and they exist to protect cardholders from unexpected charges. The merchant must get explicit consent from the cardholder before storing the credential, and must tell the cardholder the amount or the billing rule, the frequency, and how to cancel. The merchant must send a notification before each charge, or at least make the schedule visible in the customer account. The merchant must also store the scheme reference identifier from the original transaction and send it with every later transaction. These rules are enforced by the schemes, and merchants that break them can face fines and higher interchange fees. The transaction identifier chain is the technical detail that makes credential-on-file work. When the first transaction is processed, the scheme returns a transaction identifier, and the merchant stores it alongside the token. Every later merchant initiated transaction includes that identifier, which lets the issuer trace the payment back to the original customer consent. If the merchant loses this identifier, for example during a migration between payment providers, the later transactions lose their link to the consent and authorisation rates fall. A BA working on a payment provider migration must treat the preservation of these identifiers as a critical data migration requirement, and must test it before the cutover. From a business analyst perspective, card-on-file design means documenting several connected requirements. The BA specifies the consent screen, including the exact wording of the mandate terms. The BA specifies the token vault, including which token type is used and how tokens are stored. The BA specifies the transaction indicators for each payment type, and the mapping of decline codes to retry actions. The BA also specifies the customer controls, such as the ability to view, update, and delete stored cards, and the audit trail that shows when consent was given. Together these requirements form the stored credential design, and they are the first thing a scheme auditor will ask to see. For example, a customer buys a household appliance for 2,000 rupees and agrees to pay the rest in monthly instalments of 2,000 rupees. The merchant stores a network token for the card, together with the scheme reference identifier from the first payment. Each month, the merchant sends an instalment transaction with the token and the reference identifier, so the issuer can trace the charge back to the original consent. If the customer cancels the instalment plan, the merchant must delete the token and stop charging.