MIT (Merchant initiated transaction) Support

Suggest Edits

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

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 nameValue for 1stValue for 2nd onwards
    payment
    .recurringPayment
    .currentPaymentNumber    		12,3,4..
    payment
    .recurringPayment
    .totalNumberOfPayments    		Int (optional)Int (optional)
    payment
    .recurringPayment
    .recurringPaymentFrequency    		Int (mandatory)Int (mandatory)
    payment
    .recurringPayment
    .initialPaymentOrderId    		String (mandatory)
    payment
    .recurringPayment
    .recurringPaymentExiprationDate    		Datetime (mandatory)Datetime (optional)
    payment
    .recurringPayment
    .isPaymentAmountIdenticalForAllPayments    		true = Recurring Fixed Amount

    false = Recurring Variable Amount
    orderTypeAUTOMATIC_RENEWAL_OR_INSTALLMENT_PAYMENT

  • 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

Updated 11 days ago