MIT (Merchant-Initiated Transaction) Flows

Overview

CIT (Customer-Initiated Transaction): Refers to a transaction initiated by the customer while they are online on the merchant’s website. This can involve either a one-time payment or saving their card with a mandate allowing the merchant to charge them later. In cases where the customer provides a mandate but does not make an actual payment, the CIT is processed with a $0 amount.

MIT (Merchant-Initiated Transaction): Refers to a transaction initiated by the merchant without the customer being online on the website at the time.

MIT Use Cases

Recurring
In the recurring flow, MITs are for ongoing services with fixed charges at a set frequency and no predefined end date.
Examples: subscriptions to streaming services, gym memberships.

Installment
In the installments flow, the MITs are for fixed repayments of a specific total amount with a clear end date.
Examples: paying for a product in three monthly installments, financing a purchase, or loan repayments.

Top Up
In the top-up flow the MITs occur in an irregular schedule, triggered by usage or thresholds, with no predefined total.
Examples: refilling an account for a subscription or reshipping goods based on varying usage.

Split or Delayed Shipment
In the Split or Delayed Shipment flow the MITs are tied directly to the fulfillment of a specific order, where the payments are processed for goods that are either shipped in multiple parts or delayed by more than 90 days, based on the order structure or availability.
Examples: an online order where some items are in stock and others are shipped later, preorders for products that require delayed manufacturing or availability, orders fulfilled in multiple shipments due to logistical constraints.

Multi-Party Commerce
In this use case the MITs can take place either when multiple parties are involved in processing multiple authorizations associated with a single travel booking or where multiple parties in sectors other than travel are involved in processing multiple authorizations associated with a single checkout from a cardholder’s point of view.


3DS for MIT

Why Execute 3DS for MIT?

3DS is typically required for merchant-initiated transactions (MITs) in the following scenarios:

Initial Customer-Initiated Transaction (CIT) under PSD2
While MITs are generally exempt from 3DS under the “merchant-initiated transaction” exemption, 3DS is required for the initial CIT to validate the exemption and establish the necessary authentication data for subsequent MITs.

Use Cases Requiring Multiple CAVVs for a single purchase
For scenarios such as multi-party travel bookings or transactions involving multiple authorizations (e.g split shipments), 3DS need to be executed to generate multiple CAVVs tied to the same authentication.

Transactions Beyond the Validity Period of the Initial CAVV
If a merchant authorizes a transaction after the validity period of the initial CAVV has expired (e.g shipments delayed by more than 90 days), executing 3DS ensures liability protection is extended for the transaction.

Generally, merchants may also (but are not required to) use 3DS on MITs in recurring installments or top-up use cases to establish liability shift and reduce the likelihood of chargebacks in case of potential disputes.

Executing 3DS on a CIT will typically involve a challenge, whereas executing 3DS on an MIT using the 3RI extension ensures a seamless, frictionless experience. In both cases, merchants benefit from compliance and liability shift.

API Requirements for Executing 3DS with Forter on MITs and their Initial CIT

MIT Use Case

Recurring

Installment

Top Up

Split or Delayed Shipment

Multi-Party Commerce

  • *Initial CIT** (*) Order Request should include also the following fields

(*) the CIT preceding the MIT, where the buyer’s consent is provided

payment[0].allowedMerchantInitiatedTransactions

payment[0].merchantInitiated.type: RECURRING_TRANSACTION

payment[0].allowedMerchantInitiatedTransactions

payment[0].merchantInitiated.type: INSTALMENT_TRANSACTION

payment[0].allowedMerchantInitiatedTransactions

payment[0].merchantInitiated.type: TOP_UP

payment[0].allowedMerchantInitiatedTransactions

payment[0].merchantInitiated.type: SPLIT_OR_DELAYED_SHIPMENT

payment[0].allowedMerchantInitiatedTransactions

payment[0].merchantInitiated.type: OTHER_PAYMENT

  • *MIT** Order Request should include also the following fields

orderType: MERCHANT_INITIATED

payment[0].merchantInitiated.initialOrderId

payment[0].merchantInitiated.type: RECURRING_TRANSACTION

payment.recurringPayment.recurringPaymentFrequency
The number of days between transactions

payment.recurringPayment.recurringPaymentExpirationDate
The date beyond which no further authorizations will be processed. In case exist.

orderType: MERCHANT_INITIATED

payment[0].merchantInitiated.initialOrderId

payment[0].merchantInitiated.type: INSTALMENT_TRANSACTION

payment[0].recurringPayment.recurringPaymentFrequency

payment.recurringPayment.recurringPaymentExpirationDate

payment[0].recurringPayment.totalNumberOfPayments

orderType: MERCHANT_INITIATED

payment[0].merchantInitiated.initialOrderId

payment[0].merchantInitiated.type: TOP_UP

orderType: MERCHANT_INITIATED

payment[0].merchantInitiated.initialOrderId

payment[0].merchantInitiated.type: SPLIT_OR_DELAYED_SHIPMENT

orderType: MERCHANT_INITIATED

payment[0].merchantInitiated.initialOrderId

payment[0].merchantInitiated.type: OTHER_PAYMENT


API Requirements for getting PSD2 3DS recommendation from Forter on MITs and their Initial CIT


MIT Use Case

Recurring

Installment

Top Up

Split or Delayed Shipment

Multi-Party Commerce

  • *Initial CIT** (*) Order Request should include also the following fields

(*) the CIT preceding the MIT, where the buyer’s consent is provided

payment[0].allowedMerchantInitiatedTransactions

payment[0].merchantInitiated.type: RECURRING_TRANSACTION

payment[0].allowedMerchantInitiatedTransactions

payment[0].merchantInitiated.type: INSTALMENT_TRANSACTION

payment[0].allowedMerchantInitiatedTransactions

payment[0].merchantInitiated.type: TOP_UP

payment[0].allowedMerchantInitiatedTransactions

payment[0].merchantInitiated.type: SPLIT_OR_DELAYED_SHIPMENT

payment[0].allowedMerchantInitiatedTransactions

payment[0].merchantInitiated.type: OTHER_PAYMENT

  • *MIT** Order Request should include also the following fields

orderType: MERCHANT_INITIATED

payment[0].merchantInitiated.initialOrderId

payment[0].merchantInitiated.type: RECURRING_TRANSACTION

orderType: MERCHANT_INITIATED

payment[0].merchantInitiated.initialOrderId

payment[0].merchantInitiated.type: INSTALMENT_TRANSACTION

orderType: MERCHANT_INITIATED

payment[0].merchantInitiated.initialOrderId

payment[0].merchantInitiated.type: TOP_UP

orderType: MERCHANT_INITIATED

payment[0].merchantInitiated.initialOrderId

payment[0].merchantInitiated.type: SPLIT_OR_DELAYED_SHIPMENT

orderType: MERCHANT_INITIATED

payment[0].merchantInitiated.initialOrderId

payment[0].merchantInitiated.type: OTHER_PAYMENT

Trusted Auth for MIT

MIT Use Case

Recurring or Installment

Order (MIT) Req should include also the following fields

orderType: MERCHANT_INITIATED

payment.recurringPayment.recurringPaymentFrequency
The number of days between transactions

payment.recurringPayment.recurringPaymentExpirationDate
The date beyond which no further authorizations will be processed. if you don’t have a specific expiration date, leave the field empty


Chargeback Recovery for MIT


MIT Use Case

Recurring

Top Up

  • *Initial CIT** (*) Order Request should include also the following fields

(*) the CIT preceding the MIT, where the buyer’s consent is provided

payment[0].allowedMerchantInitiatedTransactions: true

payment[0].merchantInitiated.type: RECURRING_TRANSACTION

payment[0].allowedMerchantInitiatedTransactions: true

payment[0].merchantInitiated.type: TOP_UP

  • *MIT** Order Request should include also the following fields
orderType: MERCHANT_INITIATED
payment[0].merchantInitiated.initialOrderId: the order id of the initial cit
payment[0].merchantInitiated.type: RECURRING_TRANSACTION
payment.recurringPayment.recurringPaymentFrequency  

The number of days between transactions

payment.recurringPayment.recurringPaymentExpirationDate The date beyond which no further authorizations will be processed. In case exist

orderType: MERCHANT_INITIATED

payment[0].merchantInitiated.initialOrderId: the order id of the initial cit

payment[0].merchantInitiated.type: TOP_UP