Cardholder and Merchant Initiated Payments
Payments made with a card-related payment method can be divided into two categories based on who initiates them:
- Cardholder-initiated payments (CIT): These payments are created with the cardholder’s active participation. The cardholder initiates the payment online or through mail or telephone order.
- Merchant-initiated payments (MIT): These payments are created without the cardholder’s active participation. They are used in situations where the cardholder has previously provided their consent for the merchant to store their payment details and has made an agreement with the merchant for the future use of their payment details. For example, standing instruction which allows the merchant to bill card holder for monthly subscription and industry practice which allows the merchant to bill card holder for cancellation of a reservation without advance notice to the merchant.
You may want to collect payment details from your payers, store them, and then use them to process the following:
- Future CITs, as a returning payer does not need to enter their payment details again when you can offer to use the same payment details as during their previous visit.
- Future MITs, when you have an agreement with the payer.
The information can be submitted to the Mastercard Gateway to identify stored payment details and whether the transaction is cardholder or merchant-initiated. It can provide:
- Greater visibility of transaction risk levels for issuers.
- Higher authorization approval rates and completed sales.
- Improved payer experience.
- Card scheme compliance.
The following process is used to collect and store the payer’s payment details. The process complies with card scheme standards for processing CITs and MITs using stored payment details. These standards are also known as Credential on File (COF) requirements.
You can choose to store payment details in your own system, or use Gateway Tokenization or Network Tokenization, also known as card scheme tokens, that impose lower payment card industry (PCI) compliance requirements.
Collect and store payment details
- Storing the payment details in the initial transaction: In the initial transaction, inform the gateway that you want to store the payment details and intend to use them later. If you need to make any MITs related to the initial CIT, include an agreement ID in the request. The gateway stores the agreement and links the CIT or MIT to the initial CIT. If you are not handling the payer’s payment details directly yourself, you can use Gateway Tokenization.
- Using stored details in subsequent transactions In future CITs, if the customer wants to use the same payment details as before, include the payment details, or the token in your transaction request. The gateway uses the payment details or retrieves the payment credentials stored against the token and handles the payment accordingly. In future MITs, include in your transaction request both the payment details or token and the agreement ID. The gateway confirms the agreement, matches the token to the original payment details, if applicable, and handles the payment accordingly.
Use cases support for stored payment details
From the API version 74 and later, the gateway supports the following use cases when using stored payment details:
- Cardholder-initiated payments: Indicates that the transaction is initiated by the payer.
- Merchant-initiated recurring payments: A recurring payment is an agreement where the payer authorizes you to process payments for recurring bills or invoices at agreed agreed intervals. For example, weekly or monthly subscription for a gym membership.
- Merchant-initiated installment payments: An installment payment is an agreement where the payer authorizes you to split the payment for a single purchase into a number of payments processed at agreed intervals. For example, to pay for a purchase in six monthly installments.
- Merchant-initiated unscheduled payments: An unscheduled payment is an agreement where the payer authorizes you to automatically deduct funds for a payment for an agreed purchase, when required. For example, automatic top-ups when the account value falls below a threshold.
- Merchant-initiated industry practice payments: Industry practice payment is an agreement where the payment is submitted in the context of specific industry practices:
- Related or delayed charge: Additional account charge after the payment for the initial services has already been processed. For example, an additional mini-bar charge after the cardholder has checked out of a hotel.
- No show penalty: A penalty charged to the payer according to the merchant’s cancellation policy. For example, a cardholder’s cancellation of a reservation without providing proper advance notice to the merchant.
- Partial shipment: A shipment where the merchant decides to ship the goods from the same order in multiple shipments due to various reasons, such as goods unavailability or involvement of multiple suppliers.
- Merchant-initiated resubmission payments: A resubmission payment is an agreement where you resubmit an authorization for a declined or failed transaction due to insufficient funds, but the goods or services were already delivered to the customer, where the payer is no longer present.
- Although the Hosted Checkout integration uses a predefined payment page and gives you limited control over its content, you can use it to create CITs with or without stored payment details. You can also ask the customer to agree to MITs you plan to create later on.
- The merchant-initiated industry practice payment and resubmission use cases only work for Mastercard brand scheme cards.
For more information on how to perform these steps on the fields required in the transaction requests, see Credential on File Transactions.