Merchant Initiated Transaction (MIT)

Introduction

Une Merchant-Initiated Transaction (MIT) est un paiement initié sans interaction du titulaire de la carte, réalisé dans le cadre d’un contrat préexistant entre le marchand et son client. Ce modèle s’applique aux facturations récurrentes, variables ou usage-based.

Dans le cadre DSP2, une MIT peut être exemptée d’authentification SCA, à condition que :

1. Le marchand dispose d’un mandat contractuel valide,
2. Une transaction initiale CIT authentifiée (3DS) ait été réalisée.

Les MIT reposent donc sur une authentification antérieure réussie associée à un Customer et à un cardToken.

1. CIT et MIT : quelle différence ?

Customer-Initiated Transaction (CIT)

Une transaction CIT est initiée par le titulaire de la carte. Elle implique généralement une authentification 3DS.

Rôles de la CIT initiale dans un flux MIT :

• authentifier la carte et le porteur,
• valider la création d’un Customer,
• permettre la génération d’un cardToken,
• servir de référence aux MIT futures.

Merchant-Initiated Transaction (MIT)

Une MIT est déclenchée par le marchand sans intervention du porteur, conformément au mandat conclu avec le client.

Cas d’usage :

• facturation mensuelle à montant variable,
• frais ponctuels supplémentaires,
• utilisation de type usage-based.

2. Conditions nécessaires pour effectuer des MIT

Deux conditions doivent être réunies :

2.1. Exécution d’une CIT initiale authentifiée (3DS)

Cette CIT doit être :

• authentifiée via 3DS,
• capturée,
• associée à un Customer et à un cardToken.

2.2. Existence d’un mandat commercial valide

Le mandat doit couvrir :

• la nature des services,
• le montant futur (fixe ou variable),
• les conditions et fréquences de facturation,
• l’accord explicite du client sur les paiements ultérieurs.

3. Montant de la CIT initiale

Il est parfaitement conforme de réaliser une CIT initiale avec un montant symbolique (par exemple 1 € ou 0,01 €) pour :

• authentifier la carte,
• valider le contrat commercial,
• générer un token utilisable pour des MIT ultérieures.

La CIT initiale n’a pas à couvrir le montant réel des MIT futures.

Remarque : Les transactions à 0€ type “vérification / empreinte carte authentifiée” fonctionnent pour certains schémas mais n’est pas universellement supporté par les banques partenaires, d’où la recommandation d’utiliser une transaction CIT authentifiée.
Également, bien que la CIT symbolique soit techniquement acceptable, l’émetteur peut — en fonction de son profil de risque, du schéma ou de l’ancienneté — décider de déclencher un challenge 3DS lors d’une MIT ultérieure."

4. Durée de validité d’une CIT pour générer des MIT

Il n’existe pas de limite imposée par CentralPay.
La durée de validité dépend exclusivement :

4.1. De l’ACS émetteur (banque du porteur)

Les pratiques observées dans le secteur :

• conservation de la preuve d’authentification : ≈ 13 mois,
• pour certains émetteurs : jusqu’à 36 mois.

Après expiration de la preuve 3DS, les MIT peuvent faire l’objet :

• de soft declines,
• de demandes d’authentification,
• de rejets « SCA required ».

4.2. Du recours au 3DS 2.2 – 3RI

Dans certains cas, le marchand peut renouveler une authentification côté émetteur via 3RI, afin de prolonger la durée de validité du mandat.

Disponibilité schémas :

• CB : support opérationnel,
• Mastercard : support opérationnel,
• Visa : support en cours d’évolution, non fiable à date.

5. Une MIT peut-elle nécessiter une authentification 3DS ?

Oui. Une MIT peut être exceptionnellement requalifiée en CIT par l’émetteur (ACS), notamment dans les cas suivants :

• ancienneté élevée de la CIT initiale,
• suspicion de fraude,
• règles RBA de l’émetteur,
• montants atypiques ou plus élevés que prévu.

Réduire le risque de demande 3DS

• utiliser 3RI lorsque supporté,
• conserver un cadre contractuel clair,
• refaire une CIT en cas d’échecs répétés.

6. Transactions MIT ou service d’abonnement de CentralPay : comment choisir ?

Il n’est pas obligatoire de passer par le module Subscription pour effectuer des MIT.

6.1. Utiliser le service d’abonnement si :

• les montants sont fixes,
• la fréquence est récurrente,
• la logique est celle d’un abonnement.

6.2. Utiliser les transactions MIT si :

• les montants sont variables (usage-based model),
• les facturations sont ponctuelles,
• les débits doivent être initiés par le marchand.

7. Implémentation API : effectuer une transaction MIT

7.1. CIT initiale

Lors de la transaction CIT :

• création d’un customer,
• génération d’un cardTokenId,
• authentification 3DS.

7.2. Transaction MIT

Chaque transaction MIT doit inclure :

• customerId,
• cardTokenId (ou cardId),
• indication du contexte MIT dans les paramètres de transaction,
• les métadonnées utiles pour rattacher la MIT à la CIT initiale.

8. Bonnes pratiques pour fiabiliser un flux MIT

8.1. Techniques

• déclencher les MIT peu après la facturation,
• regrouper les paiements lorsque pertinent,
• utiliser 3RI pour rafraîchir l’authentification,
• conserver un cardToken stable.

8.2. Gestion des refus

• en cas de code indiquant « SCA required »,
  proposer au client une nouvelle CIT (paiement manuel),
  recréer un mandat MIT.

8.3. Contractuelles

• conserver la preuve du mandat : CGV, logs d’acceptation, contrat, page d’information client.

9. FAQ MIT

Une CIT de 1 € suffit-elle pour un mandat MIT ?

Oui, si elle est authentifiée 3DS.

Combien de temps une CIT permet-elle de générer des MIT ?

Cela dépend de l’ACS : généralement 13 à 36 mois.

Une MIT peut-elle déclencher 3DS ?

Oui, si l’ACS l’exige (RBA, ancienneté de la CIT, montants atypiques).

Dois-je utiliser Subscription pour des montants variables ?

Non, le service subscription est généralement adapté à des modèles d’abonnements fixes. Réaliser une transaction CIT initiale + des transactions MIT ad-hoc est le modèle recommandé.

Que faire si le client change de carte ?

Une nouvelle CIT est nécessaire pour générer un nouveau token.