# Recurring Payments
source: https://developer.mastercard.com/mastercard-gateway/documentation/gateway-features/cit-mit/index.md
Payments made with a [card-related payment method](https://developer.mastercard.com/mastercard-gateway/documentation/payment-methods/cards/index.md) 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 the cardholder for monthly subscription and industry practice which allows the merchant to bill the cardholder 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. Warning: You can choose to store payment details in your own system, or use [Gateway Tokenization](https://developer.mastercard.com/mastercard-gateway/documentation/security-and-fraud/tokenization/gw-tokenization/index.md) or [Network Tokenization](https://developer.mastercard.com/mastercard-gateway/documentation/security-and-fraud/tokenization/network-tokenization/index.md), also known as card scheme tokens, that impose lower payment card industry (PCI) compliance requirements.
## Collect and store payment details {#collect-and-store-payment-details}
1. **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.
2. **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.
## Recommended paths {#recommended-paths}
Select the path that matches your role and integration requirements.
| If you are a... | Then focus on... |
|----------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Enterprise merchant**, a large merchant integrating directly with Gateway APIs | **CITs** are used for payments where the cardholder is actively present. Examples include hosted checkout, digital wallet payments, and one‑time purchases. **MITs** are used when the cardholder is not present and the merchant initiates the payment. Examples include subscriptions, payment plans, and buy now, pay later. |
| **Payment service provider**, a PSP, aggregator, or payment facilitator | Implements CIT and MIT logic at the platform layer and submits correctly flagged transactions to the gateway on behalf of multiple merchants. |
| **Software vendor**, an ISV embedding payment flows into platforms | Uses CIT and MIT features as part of the products built for merchants. |
## API reference {#api-reference}
Recurring Payments use the [Pay](https://mtf.gateway.mastercard.com/api/documentation/apiDocumentation/nvp/version/100/operation/Transaction%3a%20%20Pay.html?locale=en_US) endpoint to process recurring and merchant‑initiated payment transactions as part of the standard payment flow.
For a complete list of supported APIs, see [API Reference](https://developer.mastercard.com/mastercard-gateway/documentation/api-reference/index.md).
## Versions {#versions}
These versions apply to Recurring Payments.
| If you need... | Then... |
|----------------------------|--------------------------------------------------------------------------------------------------------------|
| **To integrate to an API** | Use Version 100 of the Mastercard Gateway API for all new integrations. Available from version 74 and later. |
## FAQs {#faqs}
These questions address common topics about Recurring Payments.
From API Version 74 and later, the gateway supports the following use cases when using stored payment details:
* Cardholder‑initiated payments
* Merchant‑initiated recurring payments
* Merchant‑initiated installment payments
* Merchant‑initiated unscheduled payments
* Merchant‑initiated industry practice payments
* Merchant‑initiated resubmission payments
A cardholder‑initiated payment indicates that the transaction is initiated by the payer. A merchant‑initiated recurring payment is an agreement where the payer authorizes you to process payments for recurring bills or invoices at agreed intervals, such as a weekly or monthly subscription for a gym membership. A merchant‑initiated installment payment is an agreement where the payer authorizes you to split the payment for a single purchase into multiple payments processed at agreed intervals, such as paying for a purchase in six monthly installments. A merchant‑initiated unscheduled payment is an agreement where the payer authorizes you to automatically deduct funds for an agreed purchase when required, such as automatic top‑ups when an account balance falls below a threshold. A merchant‑initiated industry practice payment is an agreement where the payment is submitted in the context of specific industry practices, including:
* Related or delayed charge, such as an additional mini‑bar charge after hotel checkout
* No‑show penalty, charged according to the merchant's cancellation policy
* Partial shipment, where goods from the same order are shipped in multiple deliveries
A merchant‑initiated resubmission payment is an agreement where an authorization is resubmitted for a previously declined or failed transaction due to insufficient funds, when goods or services have already been delivered and the payer is no longer present. Although [Hosted Checkout](https://developer.mastercard.com/mastercard-gateway/documentation/build/hosted-checkout/index.md) uses a predefined payment page and provides limited control over its content, it can be used to create cardholder‑initiated transactions with or without stored payment details. It can also be used to obtain the customer's agreement for merchant‑initiated transactions created later. Merchant‑initiated industry practice payments and resubmission use cases are supported only for Mastercard brand scheme cards. For information about the fields required in transaction requests, see [Credential on File Transactions](https://developer.mastercard.com/mastercard-gateway/documentation/security-and-fraud/cred-file-transc/index.md).