Merchant-Initiated Transaction (MIT)

Introduction

A Merchant-Initiated Transaction (MIT) is a payment initiated without any interaction from the cardholder, carried out under a preexisting contract between the merchant and its customer. This model applies to recurring, variable, or usage-based billing.

Under PSD2, a MIT may be exempt from SCA authentication, provided that:

1. The merchant has a valid contractual authorization,
2. An initial CIT transaction authenticated using 3DS has been completed.

MITs are therefore based on a previous successful authentication combined with a Customer and a cardToken.

1. CIT and MIT: What’s the Difference?

Customer-Initiated Transaction (CIT)

A CIT transaction is initiated by the account owner. It generally involves 3DS authentication.

Roles of the Initial CIT in an MIT workflow:

• authenticate the card and the cardholder,
• confirm the creation of a Customer,
• allow the generation of a cardToken,
• serve as a reference for future MITs.

Merchant-Initiated Transaction (MIT)

An MIT is initiated by the Merchant without any action on the part of the account holder, in accordance with the agreement entered into with the customer.

Use Cases:

• monthly billing with a variable amount,
• additional one-time fees,
• usage-based model.

2. Requirements for Conducting MITs

Two conditions must be met:

2.1. Processing an Initial Authenticated CIT (3DS)

This CIT must be:

• authenticated via 3DS,
• captured,
• associated with a Customer and a cardToken.

2.2. Existence of a Valid Commercial Power of Attorney

The scope of work must include:

• the nature of the services,
• the future amount (fixed or variable),
• billing terms and frequency,
• the customer’s explicit consent to future payments.

3. Amount of the Initial CIT

It is perfectly acceptable to make an initial CIT payment in a nominal amount (for example , €1 or €0.01) in order to:

• authenticate the card,
• approve the commercial contract,
• Generate a token that can be used for future MITs.

The initial CIT does not have to cover the actual amount of future MITs.

Note: Zero-euro transactions of the “verification/authenticated card imprint” type work for certain schemes but are not universally supported by partner banks; hence the recommendation to use an authenticated CIT transaction.
Additionally, although a nominal CIT transaction is technically acceptable, the issuer may—depending on its risk profile, the payment scheme, or the account’s tenure—decide to trigger a 3DS challenge during a subsequent MIT transaction."

4. Validity Period of a CIT for Generating MITs

There is no limit imposed by CentralPay.
The validity period depends solely on:

4.1. From the issuing ACS (the holder’s bank)

Practices observed in the sector:

• Retention period for authentication records: ≈ 13 months,
• For certain issuers: up to 36 months.

After the 3DS token expires, MITs may be subject to:

• of soft declines,
• authentication requests,
• “SCA required” rejections.

4.2. On the Use of 3DS 2.2 – 3RI

In some cases, the Merchant may renew an issuer-side authentication via 3RI in order to extend the mandate’s validity period.

Availability of diagrams:

• CB: operational support,
• Mastercard: Operational Support,
• Visa: Support is currently under development and is not reliable at this time.

5. Can an MIT require 3DS authentication?

Yes. An MIT may, in exceptional cases, be reclassified as a CIT by the issuer (ACS), particularly in the following cases:

• long history of the original CIT,
• suspected fraud,
• the issuer’s RBA rules,
• amounts that are unusual or higher than expected.

Reducing the Risk of 3DS Requests

• Use 3RI when supported,
• maintain a clear contractual framework,
• Take the CIT again in the event of repeated failures.

6. MIT Transactions or CentralPay’s Subscription Service: Which Should You Choose?

It is not required to use the Subscription module to perform MITs.

6.1. Use the subscription service if:

• The amounts are fixed,
• the frequency is recurring,
• The concept is similar to that of a subscription.

6.2. Use MIT transactions if:

• The amounts vary (usage-based model),
• Invoices are issued on a one-time basis,
• Debit transactions must be initiated by the Merchant.

7. API Implementation: Perform an MIT Transaction

7.1. Initial CIT

During the CIT transaction:

• creation of a web customer,
• Generating a cardTokenId,
• 3DS authentication.

7.2. MIT Transaction

Each MIT transaction must include:

• customerId,
• cardTokenId (or cardId),
• specifying the MIT context in the transaction parameters,
• the metadata needed to link the MIT to the original CIT.

8. Best Practices for Improving the Reliability of an MIT Workflow

8.1. Techniques

• initiate MITs shortly after billing,
• combine payments when appropriate,
• use 3RI to refresh authentication,
• Maintain a stable cardToken.

8.2. Handling Refuses

• If the code indicates “SCA required” (
  ), offer the customer a new CIT (manual payment); if the code indicates “MIT required” (
  ), recreate an MIT mandate.

8.3. Contract Workers

• Keep proof of the order: Terms and Conditions, acceptance logs, contract, customer information page.

9. MIT FAQ

Is a CIT of 1 € sufficient for an MIT mandate?

Yes, if it is 3DS-authenticated.

How long does a CIT continue to generate MITs?

It depends on the ACS: generally 13 to 36 months.

Can an MIT trigger 3DS?

Yes, if the ACS requires it (RBA, CIT tenure, atypical amounts).

Should I use “Subscription” for variable amounts?

No, the subscription service is generally designed for fixed subscription models. The recommended approach is to perform an initial CIT transaction followed by ad hoc MIT transactions.

What should you do if a customer changes their card?

A new CIT is required to generate a new token.