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.
Incremental authorizations (a type of industry practice MIT) are supported via the specific payments/{paymentId}/increments operation in the API.
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 |
- 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_showindustry practice MIT to charge any agreed-to no show fee, and in this case thecredentialOnFilefield should not be present. - For payments including the
accountTokenblock (i.e. using a token) thecredentialOnFilefield must be set tostored. 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 |