Credential on file (COF) / Merchant initiated transactions (MIT)

Credential on file (also known as stored credentials)

Merchants and acquirers are required to identify the initial storage and subsequent use of stored payment credentials (i.e., account details) during payment processing. This allows every stakeholder in the payment value chain to manage risk and fraud, resulting in better approval rates, fewer customer complaints and an improved cardholder experience.

To identify that payment credentials are being stored for subsequent use, the credentialOnFile field of the payment request should be set to initial_storage. To identify that stored payment credentials are being used, the credentialOnFile field of the payment request should be set to stored.

Payment credentials are considered stored payment credentials when stored by the merchant or its agent, or a payment facilitator (PF) to process future purchases for a cardholder.

Payment credentials received by merchants from third parties, including pass-through digital wallets, that are not stored by the merchant or its agent or a payment facilitator (PF) are not considered stored credentials. The following example use cases are not considered stored credentials:

• Payment credentials received by a merchant on a purchase from Visa/Mastercard Click to Pay and that are not stored by that merchant or its agent or a PF are not considered stored credentials.
• When a merchant or its agent, or a PF stores the credentials to complete a single transaction or a single purchase for a cardholder (including multiple authorizations related to the particular transaction), the credentials are not considered stored credentials.

Merchant initiated transactions

Transactions are either Cardholder Initiated Transactions (CIT) or Merchant Initiated Transactions (MIT).

• Cardholder Initiated Transaction (CIT): Occurs when the cardholder actively engages in the payment process.
• Merchant Initiated Transaction (MIT): Takes place when the cardholder has granted permission for their card to be charged without active engagement. An MIT follows a prior CIT that enables the subsequent charges.

Merchants and acquirers should be able to identify the type of MIT and link the MIT to the cardholder-merchant initial interaction (CIT).

For standing instruction MITs the type should be specified in the standingInstruction block of the payment request. For industry practice MITs the type should be specified in the industryPractice block of the payment request. The schemeTransactionId field of the payment request is used to link MIT transactions to the cardholder-merchant initial interaction.

note

Incremental authorizations (a type of industry practice MIT) are supported via the specific payments/{paymentId}/increments operation in the API.

Linking Subsequent MITs to the Initial Transaction

For recurring Merchant-Initiated Transactions (MITs), merchants must reference the initial transaction when submitting subsequent authorization requests.

When the initial recurring payment authorization is approved, the card scheme returns a schemeTransactionId in the authorization response. This identifier represents the first transaction in the recurring series that was authenticated by the cardholder.

For all subsequent recurring payment authorization requests, the merchant must:

• Include the schemeTransactionId received in the initial authorization response.
• Populate it in the appropriate scheme transaction reference field of the authorization request.

The schemeTransactionId acts as a persistent reference that links subsequent MITs to the original cardholder initiated transaction. Issuers use this reference to validate that the transaction is part of an approved recurring series and to apply the appropriate authorization and risk rules.

Failure to provide the correct schemeTransactionId may result in increased decline rates or issuer rejection of subsequent recurring transactions.

Authorization retry strategy

Merchants performing Merchant-Initiated Transactions (MIT) must use transaction response data to inform authorization retry decisions. Certain declined transactions must not be retried, while others may be retried under defined conditions.

When determining whether to retry a declined transaction, merchants must evaluate:

• responseCodeCategory for Visa. See full list of Response Category codes.
• merchantAdviceCode for Mastercard. See full list of Merchant advice codes.

Transactions that must not be retried

To align with scheme MIT (Merchant Initiated Transaction) compliance practices, the following declined transactions must not be reattempted:.

• Visa
  • All transactions with issuer_will_never_approve as responseCodeCategory.
• Mastercard
  • All transactions with merchantAdviceCode equal to 03 or 21.

Merchants should instead request an alternative payment method or contact the cardholder. A transaction is considered a retry if it meets all of the following criteria within a 30-day period:

• Same card number
• Same expiry date
• Same merchant
• Same transaction amount

COF/MIT scenarios

Case	credential on file	standing instruction	industry practice	scheme transaction id
Credential on file initial storage CIT	initial_storage	-	-	-
Credential on file stored credentials CIT	stored	-	-	-
Recurring initial CIT	initial_storage	recurring initial	-	-
Recurring subsequent MIT	stored	recurring subsequent	-	present
Unscheduled initial CIT	initial_storage	unscheduled initial	-	-
Unscheduled subsequent MIT	stored	unscheduled subsequent	-	present
Delayed charges MIT	- not present - stored	-	delayed_charges	present
No show MIT	- not present - stored	-	no_show	present
Reauthorization MIT	- not present - stored	-	reauthorization	present
Resubmission MIT	- not present - stored	-	resubmission	present

note

• Some industry practice MITs may not involve stored credentials. For example, if a hotel kept a cardholder's payment credentials during reservation to cover any related expenses for that specific reservation and not for future reservations, then the payment credentials are not considered stored credentials; if the cardholder does not show up to the hotel, the hotel may initiate a no_show industry practice MIT to charge any agreed-to no show fee, and in this case the credentialOnFile field should not be present.
• For payments including the accountToken block (i.e. using a token) the credentialOnFile field must be set to stored. Please check the tokenization section for more information about tokens.

Credential on file initial storage CIT

Shopper makes a purchase on merchants website and agrees to save the card information for future purchases.

Field	Value
credentialOnFile	initial_storage

Credential on file stored credentials CIT

Shopper makes a purchase with a card previously saved.

Field	Value
credentialOnFile	stored

Recurring initial CIT

Cardholder authorizes the merchant to store the card data to pull funds from his account automatically at regular intervals for the goods and services provided to them on an ongoing basis. The amount could be fixed or variable.

Field	Value
credentialOnFile	initial_storage
standingInstruction.type	recurring
standingInstruction.mode	initial

Recurring subsequent MIT

Merchant pulls funds using the card previously stored. Used typically in subscriptions of VOD (fixed amount) or phone company billing (variable amount).

Field	Value
credentialOnFile	stored
standingInstruction.type	recurring
standingInstruction.mode	subsequent
schemeTransactionId	present

Unscheduled initial CIT

Cardholder authorizes the merchant to store the card data to pull funds from his account as needed.

Field	Value
credentialOnFile	initial_storage
standingInstruction.type	unscheduled
standingInstruction.mode	initial

Unscheduled subsequent MIT

Merchant pulls funds using the card previously stored. For example, auto top-ups when the account value falls below a limit.

Field	Value
credentialOnFile	stored
standingInstruction.type	unscheduled
standingInstruction.mode	subsequent
schemeTransactionId	present

Delayed charges MIT

Charges that are delayed or postponed in comparison to the date of purchase or service provision. They are commonly used in hotels and car rentals.

Field	Value
credentialOnFile	- not present - stored
industryPractice.type	delayed_charges
schemeTransactionId	present

No show MIT

Transaction where the merchant is enabled to charge for services that the consumer entered into an agreement to purchase, but did not meet the terms of the agreement, typically used in hotels and restaurants.

Field	Value
credentialOnFile	- not present - stored
industryPractice.type	no_show
schemeTransactionId	present

Reauthorization MIT

Process of requesting authorization to charge a credit or debit card again after a specific period of time. This occurs when an initial transaction is made, but the merchant needs to obtain additional authorization before processing the payment.

• A split or delayed shipment occurs when not all the goods ordered are available for shipment at the time of purchase. If the fulfillment of the goods takes place after the authorization validity period, a separate authorization can be performed to ensure that consumer funds are available.
• Extended stay hotels, car rentals, and cruise lines. A reauthorization is used for stays, voyages, and/or rentals that extend beyond the authorization validity period.

Field	Value
credentialOnFile	- not present - stored
industryPractice.type	reauthorization
schemeTransactionId	present

Resubmission MIT

Action of processing a payment again after an initial failed or rejected attempt. This is done in order to successfully complete the transaction by addressing the problems or errors that caused the initial failure.

Field	Value
credentialOnFile	- not present - stored
industryPractice.type	resubmission
schemeTransactionId	present