Overview

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.

Liability Shift
3DS on the initial transaction will result in a liability shift for the first transaction only, and not for the recurring payments.

PSD2

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.

Non PSD2

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.

Fraud Decision

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.

Process overview

MIT Consent Flow

In order for Forter to support a merchant with MIT payments the following should apply:

• The Merchant should send, in the /orders request, the following fields:

  Field Name	Value	Description
  payment.allowedMerchantInitiatedTransactions	bool	The indication for CIT with consent
  OrderType	MERCHANT_INITIATED	The indication for MIT

• In case consent was provided, and the transaction falls under PSD2, it will be routed to 3DS

• In case that the Order Type is MIT, the transaction will not be routed to 3DS

Recurring Flow

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	CIT	MIT
  payment .recurringPayment .currentPaymentNumber	1	2,3,4.. Required (for 3DS)
  payment .recurringPayment .totalNumberOfPayments	Int (optional)	Int Required (for 3DS)
  payment .recurringPayment .recurringPaymentFrequency	Enum {DAILY, WEEKLY, MONTHLY, ANNUAL} Required for 3DS	Enum {DAILY, WEEKLY, MONTHLY, ANNUAL} Required for 3DS
  payment .recurringPayment .initialPaymentOrderId		Required (for 3DS)
  payment .recurringPayment .recurringPaymentExpirationDate	Datetime (mandatory)	Datetime Optional
  payment .recurringPayment .isPaymentAmountIdenticalForAllPayments	true = Recurring Fixed Amount false = Recurring Variable Amount	Required (for 3DS)
  orderType		AUTOMATIC_RENEWAL_OR_INSTALLMENT_PAYMENT Required

• Under PSD2, the first transaction will always be sent to 3DS, recurring payments (MIT) will get MIT exclusion - REQUEST_SCA_EXCLUSION_MIT

• Outside of PSD2, the 2nd onwards transaction will never be routed to 3DS, as there is no user interaction, so 3DS is not supported.

Fields description

• currentPaymentNumber
  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
• totalNumberOfPayments
  Optional
  If it’s known how many payments are expected
• recurringPaymentFrequency
  Mandatory on 1st payment.
  What will be the frequency of payments
• initialPaymentOrderId
  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.
• recurringPaymentExiprationDate
  Mandatory on 1st payment
  What is the expiration date of the recurring payments.
• isPaymentAmountIdenticalForAllPayments
  Mandatory on 1st payment
  Are the recurring payments planned to be in the same amount or varying amounts