Transaction initiée par le marchand (MIT – 3RI)

Le flux 3RI (3DS Requestor Initiated) s’applique aux transactions initiées par le marchand (MIT — Merchant-Initiated Transaction) : le marchand déclenche le débit sans intervention du porteur, dans le cadre d’un mandat préexistant, sur la base d’une transaction CIT authentifiée antérieurement.

Il couvre l’ensemble des cas MIT : facturations récurrentes, montants variables, modèles usage-based, frais ponctuels, débits différés (no-show, pénalités), pas seulement les abonnements à montant fixe.

👉 Si le porteur est présent et valide lui-même le paiement, utilisez le flux BRW. Pour le cadre contractuel, les exemptions d’authentification (SCA) et la durée de validité d’une CIT, consultez la page Bonnes pratiques — Merchant Initiated Transaction (MIT).

1. Prérequis : une transaction CIT déjà authentifiée

Le porteur étant absent, le 3RI ne ré-authentifie personne : il réutilise la preuve d’authentification produite lors d’une transaction CIT (porteur présent) réalisée précédemment via le flux BRW.

Lors de cette CIT, le serveur de la banque émettrice qui a authentifié le porteur — l’ACS (Access Control Server) — a généré un identifiant unique pour cette authentification : l’acsTransID. C’est ce acsTransID que vous rattacherez à chacune de vos MIT, pour prouver à la banque que la carte a bien été authentifiée une première fois avec le consentement du porteur.

⚠️ Conservez l'acsTransID de la CIT. Sans CIT authentifiée préalable — et donc sans acsTransID — une transaction 3RI ne peut pas aboutir. Si vous n'en avez pas, réalisez d'abord une CIT en BRW pour authentifier et tokeniser la carte.

2. Authentification (3RI)

L’appel est adressé à l’URL 3ds2/authentication de l’API CentralPay, comme pour le flux BRW, mais avec deux différences clés :

• Le canal est différent. deviceChannel=03 indique une transaction initiée par le marchand (3RI), sans navigateur du porteur. Les paramètres browser* du flux BRW sont donc inutiles ici.
• On référence la CIT. L’acsTransID conservé à l’étape 1 est placé dans le champ threeDSReqPriorRef, qui désigne « l’authentification précédente à laquelle se rattache cette transaction ».

Identification de la carte. Le porteur étant absent, on ne saisit pas de carte en séance : on référence la carte déjà stockée sur le client (Customer) en transmettant customerId + cardId.

💡 N'envoyez qu'une seule source de carte. Combiner deux sources (par ex. cardId + un token, ou un PAN + un token) déclenche l'erreur « There is no unique source of card » (voir la FAQ).

Exemple (curl) :

curl --location --request POST 'https://test-api.centralpay.net/v2/rest/3ds2/authentication' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA==' \
--data-urlencode 'customerId=aae4d8c0-a555-4c2f-bfdf-18d5636b78a4' \
--data-urlencode 'cardId=44d0691b-b117-4799-ba07-31e0b02c5b08' \
--data-urlencode 'pointOfSaleId=08960d92-874b-4447-800b-aaa53fa976f5' \
--data-urlencode 'deviceChannel=03' \
--data-urlencode 'messageCategory=01' \
--data-urlencode 'acctType=03' \
--data-urlencode 'cardExpiryDate=9999' \
--data-urlencode 'purchaseAmount=4880' \
--data-urlencode 'purchaseCurrency=978' \
--data-urlencode 'purchaseExponent=2' \
--data-urlencode 'purchaseDate=20230101122345' \
--data-urlencode 'recurringExpiry=20330101' \
--data-urlencode 'recurringFrequency=1' \
--data-urlencode 'chAccAgeInd=03' \
--data-urlencode 'chAccChange=20220901' \
--data-urlencode 'chAccDate=20220901' \
--data-urlencode 'email=support@centralpay.eu' \
--data-urlencode 'nbPurchaseAccount=2' \
--data-urlencode 'paymentAccAge=20221001' \
--data-urlencode 'paymentAccInd=03' \
--data-urlencode 'threeDSReqPriorAuthMethod=02' \
--data-urlencode 'threeDSReqPriorAuthTimestamp=202209010123' \
--data-urlencode 'threeDSReqPriorRef=375d90ad-3873-498b-9133-380cbbc8d99d' \
--data-urlencode 'threeDSRequestorDecReqInd=N' \
--data-urlencode 'threeDSRequestorAuthenticationInd=02' \
--data-urlencode 'threeRIInd=01'

2.1. Explication des principaux paramètres

Paramètre	Description
deviceChannel	03 → 3DS Requestor Initiated (transaction initiée par le marchand, sans navigateur du porteur)
messageCategory	01 → PA (Payment Authentication) = Authentification rattachée à un paiement (ex. transaction récurrente) 02 → NPA (Non-Payment Authentication) = authentification hors paiement (ex. enregistrement ou vérification d’une carte sans débit).
threeDSReqPriorRef	doit contenir l’acsTransID de la transaction CIT (BRW) précédente (voir étape 1)
purchaseAmount	montant de l’achat courant
purchaseCurrency	monnaie au format ISO
purchaseExponent	unité mineure de la monnaie courante
purchaseDate	date de l’achat
recurringExpiry	date après laquelle plus aucune autorisation ne pourra être effectuée
recurringFrequency	nombre de jours minimum entre deux autorisations
acctType	type de compte (03 = debit)
chAccAgeInd	ancienneté du compte du titulaire auprès du demandeur 3DS : 01 → pas de compte 02 → créé durant la transaction 03 → moins de 30 jours 04 → entre 30 et 60 jours 05 → plus de 60 jours
chAccChange	date de dernière modification du compte du titulaire (format YYYYMMDD)
chAccDate	date d’ouverture du compte du titulaire (format YYYYMMDD)
nbPurchaseAccount	nombre d’achats effectués avec ce compte au cours des six derniers mois
paymentAccAge	date d’inscription du compte de paiement sur le compte du titulaire
paymentAccInd	ancienneté de l’inscription du compte de paiement : 01 → pas de compte 02 → créé durant la transaction 03 → moins de 30 jours 04 → entre 30 et 60 jours 05 → plus de 60 jours
threeDSReqPriorAuthMethod	Méthode d’authentification de la CIT initiale : 01 → si frictionless 02 → si le porteur a relevé un challenge 03 → AVS 04 → autre
threeDSReqPriorAuthTimestamp	date et heure (UTC) de l’authentification précédente (format YYYYMMDDHHMM)
threeDSRequestorDecReqInd	N → ne pas utiliser l’authentification découplée
threeDSRequestorAuthenticationInd	02 → transaction récurrente
threeRIInd	Type de transaction 3RI : 01 → transaction récurrente 02 → transaction échelonnée 03 → ajout de carte 04 → maintenance 05 → vérification de compte 06 → expédition fractionnée/différée 07 → rechargement 08 → vente par correspondance 09 → vente par téléphone 10 → vérification statut whitelist 11 → autre paiement

Exemple de réponse :

{
    "threeDSServerTransID": "67dc456c-6c7a-987f-92cf-f68752525d0c",
    "transStatus": "Y",
    "eci": "02",
    "contractId": "fb8736a5-8741-19b6-9d38-ec135888e0bf"
}

Ici, threeDSServerTransID est l’identifiant de l’opération généré par CentralPay (à reporter dans la transaction), et eci (Electronic Commerce Indicator) indique le niveau d’authentification obtenu, qui conditionne le transfert de responsabilité en cas de fraude.

2.2. Statuts retournés (transStatus) et conduite à tenir

L’objectif est d’obtenir une authentification sans friction (frictionless), c’est-à-dire un transStatus = Y. Tentez systématiquement le 3RI, puis agissez selon le transStatus retourné.

ℹ️ Le support du 3RI dépend du scheme de la carte et de la version 3DS de la banque émettrice : il n'est jamais garanti à l'avance. D'où la conduite « best effort » ci-dessous — vous tentez le 3RI, et vous ne vous appuyez sur son résultat que s'il est positif.

✅ Authentification réussie — exploitez le résultat (transfert de responsabilité)

Statut (transStatus)	Signification
Y	Authentification réussie.
A	Tentative effectuée. Non authentifié / vérifié, mais une preuve de tentative est fournie.

→ Réalisez la transaction en transmettant les données 3DS issues du 3RI (voir étape 3). Le transfert de responsabilité vers l’émetteur s’applique.

⚠️ 3RI non abouti — réalisez la transaction sans authentification (« best effort »)

Statut (transStatus)	Signification
N	Non authentifié / compte non vérifié.
U	Authentification / vérification impossible (problème technique ou autre).
I	Information seulement.
C / D	Challenge demandé (impossible en MIT car porteur absent — voir note ci-dessous).

→ Vous pouvez réaliser la transaction classique sans les données 3RI : le Customer (customerId + cardId) assure le chaînage automatique à la CIT initiale. Attention : dans ce cas, le transfert de responsabilité ne s’applique pas (risque de contestation accru) et le risque de refus de l’autorisation est plus élevé.

⚠️ Challenge en MIT (C / D). Un challenge suppose la présence du porteur, par définition absent en MIT. Deux cas : si le porteur peut revenir (ex. abonnement avec espace client), rejouez une CIT en BRW pour réauthentifier la carte ; sinon, traitez-le comme un 3RI non abouti et réalisez la transaction sans authentification (best effort). Voir Bonnes pratiques — MIT.

❌ Refus explicite — ne pas tenter la transaction

Statut (transStatus)	Signification
R	Authentification rejetée : l’émetteur demande de ne pas tenter l’autorisation.

→ N’effectuez pas la transaction, même sans 3RI.

3. Transaction

Une fois l’authentification 3RI réussie (Y ou A), renseignez les données 3DS suivantes dans l’appel transaction :

• 3ds[threeDSServerTransID] = threeDSServerTransID généré par l’authentification 3RI (pas celui d’une transaction précédente)
• 3ds[status] = transStatus
• 3ds[eci] = eci (obligatoire si disponible)
• 3ds[xid] = paramètre custom, référence libre destinée aux marchands

⚠️ N'envoyez pas 3ds[cavv] en 3RI. Le cavv (Cardholder Authentication Verification Value, le cryptogramme qui prouve l'authentification) est propre au flux BRW ; il est absent de la réponse 3RI et ne doit pas être transmis ici.

Exemple (curl) :

curl --location --request POST 'https://test-api.centralpay.net/v2/rest/transaction' \
--header 'Origin: https://example.centralpay.net' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA==' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'currency=EUR' \
--data-urlencode 'amount=1500' \
--data-urlencode 'endUserIp=9.64.32.8' \
--data-urlencode 'endUserLanguage=ita' \
--data-urlencode 'merchantTransactionId=cpcg_12654de89ce44' \
--data-urlencode 'pointOfSaleId=1beb8574-cf4c-4b12-b065-d12b3f0eaa90' \
--data-urlencode 'browserUserAgent=Mozilla/5.0 (iPhone; CPU iPhone OS 16_1_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Mobile/15E148 Safari/604.1' \
--data-urlencode 'browserAcceptLanguage=it_IT' \
--data-urlencode 'paymentRequestBreakdownId=5485d7e6-60c3-753c-94d3-682eaaf9ae6e' \
--data-urlencode 'email=support@centralpay.eu' \
--data-urlencode 'receiptEmail=support@centralpay.eu' \
--data-urlencode 'capture=true' \
--data-urlencode 'customerId=aae4d8c0-a555-4c2f-bfdf-18d5636b78a4' \
--data-urlencode 'cardId=44d0691b-b117-4799-ba07-31e0b02c5b08' \
--data-urlencode 'order[cardholderEmail]=support@centralpay.eu' \
--data-urlencode 'order[firstName]=John' \
--data-urlencode 'order[lastName]=Doe' \
--data-urlencode 'source=EC' \
--data-urlencode '3ds[xid]=35876533346561303461' \
--data-urlencode '3ds[eci]=02' \
--data-urlencode '3ds[status]=Y' \
--data-urlencode '3ds[threeDSServerTransID]=67dc456c-6c7a-987f-92cf-f68752525d0c'

ℹ️ Cas « best effort » (3RI non abouti). Si le 3RI n'a pas abouti (transStatus autre que Y/A, et hors R), réalisez la même transaction sans l'objet 3ds[...] : le Customer (customerId + cardId) suffit à chaîner l'opération à la CIT initiale. Le transfert de responsabilité ne s'applique alors pas.

À lire aussi : Bonnes pratiques — Merchant Initiated Transaction (MIT) pour le cadre contractuel, le mandat et les exemptions d’authentification (SCA).