Recurring/replenishment transactions is a flow in which the card-holder gives consent for future payments that will be done by the merchant. This can include cases such as subscription, pre-order, etc.
The 1st transaction is done by the card-holder and they give their permission to do “follow up charges”. This is called a Mandate. The mandate can be for a fixed or variable amount.
The mandate can be part of an actual online payment (e.g. paying for the first month / first product), or can be without any actual online payment (e.g. save the card and register to get a first month for free).
When the customer mandates the merchant to charge them later, the 2nd and onwards transactions are then initiated by the merchant (MIT) and without user interaction.
CIT(Customer Initiated Transaction) - Means that the customer was online on the website and initiated the transaction, whether a one time transaction or saved the card with a mandate for the merchant to charge them later. In cases that the customer provided a mandate but did not make an actual payment, the CIT will be for a $0 amount.
MIT*(Merchant initiated Transaction) - Means that the merchant initiated the transaction, while the customer was not online on the website.
3DS on the initial transaction will result in a liability shift for the first transaction only, and not for the recurring payments.
Under PSD2, the consent the customer is giving to charge him later (by the merchant), requires SCA, meaning 3DS with a challenge.
The 3DS must be done at the time of the consent.
- If the time of the consent is the time of an online purchase, the 3DS will be done on the purchase and will be sufficient for the recurring transactions. The recurring transaction will be linked to the first online transaction.
- If the time of the consent is the time of saving the card and there is no online transaction, the 3DS will be done on a $0 auth, and the recurring transaction will be linked to the $0 auth.
- If the time of the consent is anytime after the card was saved, at the time of the consent, 3DS must be done on a $0 auth.
Therefore, merchants that are obligated to follow PSD2 regulation, should create a flow that supports initiating a 3DS transaction when the consent is given by the consumer.
Under PSD2 regulation, since this flow allows merchants to initiate additional transactions, the requirement is stricter to the 1st transaction, and SCA is always required.
The recurring payments (MIT transactions) are excluded from PSD2, as they were not initiated by a consumer. These transactions should be processed by the merchant’s PSP as MIT (merchant initiated transactions) that is linked to the original transaction of the consent, that includes successful authentication.
For Non PSD2 transactions, there isn’t any SCA requirement, so 3DS will be applied on the first transaction only if it will be required for risk perspective (borderline transaction), other cases 3DS will not be applied on the first transaction.
Recurring transactions will never have 3DS applied to them, as 3DS is not supported when the consumer is not around.
First transaction - Mandatory be sent to Forter for a fraud decision
Recurring transactions (MIT) - its recommended to send the recurring transaction to Forter for a decision. Based on the business case, its recommended to consult with a Forter Solution Consultant on the need.
In order for Forter to support a merchant with a recurring business the following should apply:
The Merchant should send, in the /orders request, the following recurring-related fields for both the first and second onwards according to the list below.
Field name Value for 1st Value for 2nd onwards payment
1 2,3,4.. payment
Int (optional) Int (optional) payment
Int (mandatory) Int (mandatory) payment
String (mandatory) payment
Datetime (mandatory) Datetime (optional) payment
true = Recurring Fixed Amount
false = Recurring Variable Amount
Under PSD2, the first transaction will always be sent to 3DS, recurring payments (MIT) will get MIT exclusion -
Outside of PSD2, the 2nd onwards transaction will never be routed to 3DS, as there is no user interaction, so 3DS is not supported.
Required on all transactions that are recurring
Indicated if it’s the first transaction in the recurrence.
Needed so that Forter can provide 3DS or recommend exclusion
If it’s known how many payments are expected
Mandatory on 1st payment.
What will be the frequency of payments
Mandatory for 2+ payments
Unique identifier of the 1st payment (parent) to associate the recurring payments with the original one.
This should be the same identifier provided to the PSP on authorization on MIT request.
Mandatory on 1st payment
What is the expiration date of the recurring payments.
Mandatory on 1st payment
Are the recurring payments planned to be in the same amount or varying amounts
Updated 4 months ago