Introduction
L’entrée en application de la version 2 de la Directive des Services de Paiement (DSP2) entraîne la nécessité d’authentifier le titulaire de la carte (porteur) lors des transactions de paiement.
Cette authentification est réalisable lorsque le porteur est présent c'est-à-dire lors de la création de la transaction, au moment du passage de la commande (on parlera de « CIT » ou « Customer Initiated Transaction »).
En revanche, l’authentification n’est pas, à proprement parler, réalisable lorsque le porteur n’est pas présent et que la transaction est initiée par le commerçant (on parlera de « MIT » ou « Merchant Initiated Transaction »).
Dans ce deuxième cas, le commerçant doit chaîner la MIT à une CIT « origine », par le biais d’un identifiant de chaînage (ou identifiant de regroupement) pour être en conformité avec la DSP2.
L'objectif de ce document est d'expliquer le principe, et la mise en œuvre de ce chaînage dans les différents cas d’usage recensés.
Description et principe
A qui s'adresse ce document ?
Ce document s’adresse aux commerçants et à leurs équipes techniques qui souhaitent mettre en place le chaînage de transaction sur leur site de commerce électronique, pour les moyens de paiement suivants :
- CB
- VISA/VPAY/ELECTRON
- MASTERCARD/MAESTRO
- AMEX
Pour avoir une vue d’ensemble de la solution Mercanet, nous vous conseillons de consulter les documents suivants :
- Présentation fonctionnelle ;
- Guide de Configuration des fonctionnalités.
Qualification des transactions
La réglementation prévoit donc différentes qualifications, qui déterminent l’obligation d’appliquer ou non de l’authentification forte ; parmi celles-ci, les CIT et les MIT :
Customer Initiated Transaction via internet | Customer Initiated Transaction via mail ou téléphone | Merchant Initiated Transaction |
---|---|---|
Transaction initialisée par le porteur, via un canal
électronique (internet) :
|
Transaction initialisée par le porteur via un canal non
électronique (MO/TO) :
|
Transaction initialisée par le commerçant sans le concours du porteur, quel que soit le canal. |
Ces transactions sont soumises à l’obligation d’authentification forte du porteur. | Ces transactions ne sont pas soumises à l’obligation d’authentification forte du porteur. | Ces transactions ne sont pas soumises à l’obligation
d’authentification forte du porteur. Toutefois, elles doivent être liées à la CIT (par le biais du chaînage). |
Objectif et principe
Le chaînage s’effectue à l’aide d’un identifiant de chaînage ou identifiant de regroupement. C’est une référence unique de transaction renseignée par l’émetteur dans la réponse à la demande d’autorisation (ou de renseignement) de la CIT.
Selon le cas :
- On parlera de STI ou Scheme Transaction Identifier pour l’identifiant fourni par l’émetteur lors de la réponse à la demande d’autorisation (aussi appelé NTI network_transaction_id),
- On parlera de iSTI ou initial Scheme Transaction Identifier pour l’identifiant de référence qui doit être fourni dans les transactions subséquentes.
Un STI peut donc devenir un iSTI si il est utilisé pour réaliser un chaînage.
Le STI permet la mise en place du chaînage. Cet identifiant de chaînage doit être conservé, pour être retransmis dans les transactions subséquentes (MIT). Ainsi repris, l’identifiant de chaînage permettra aux émetteurs d’identifier une série de transactions liées entre elles et de garantir qu’une authentification a été mise en œuvre lors de leur initialisation.
Ce principe s'applique quel que soit la version de protocole 3DS utilisé (3DSv2, 3DSv1).
Pour bénéficier d'une garantie de paiement dans le cas de paiement multiple à l'expédition CB, sur des MIT qui interviennent dans les 30 jours qui suivent l'authentification CIT, il faut également renseigner les 4 champs suivants :
Champs Sips | Champs CB2A DA | Champs CB2A remise | Description CB2A |
---|---|---|---|
initialHolderAuthentProgram | 56-0046-01 | 59-0046-01 | Version majeure du protocole 3DS |
initialAuthentDateTime | 56-0046-05 | 59-0046-05 | Date de l'authentification |
initialHolderAuthentType | 59-0420-05-01 | 58-0420-05-01 | Type d'authentification 3DS |
initialChallengeMode3DS | 59-0420-05-02 | 58-0420-05-02 | Souhait commerçant pour l'authentification |
Cas d’usage concernés
Selon le cas d’usage, le chaînage sera requis ou non.
En partant du principe que la commande correspond à l’acte d’achat en présence du porteur, les questions à se poser sont les suivantes :
Voici les fonctions à utiliser pour le chaînage :
duplicate | cardOrder ou walletOrder |
---|---|
|
La version du connecteur doit être impérativement
supérieure ou égale à 2.28 pour accéder aux champs suivants :
|
Voici la liste des cas d'usages concernés par le chaînage :
- Paiement unique à l'expédition avec expédition prévue plus de 6 jours après la commande (voir documentation paiement multiple à l'expédition : une seule CIT 6 jours après la CIT)
- Paiement multiple à l'expédition
- Paiement en plusieurs fois
- Abonnement à montant variable
Cas particuliers
La carte de paiement est expirée
En cas d'expiration de la carte, vous sollicitez le porteur pour qu'il revienne saisir son numéro de carte avec sa date de validité, comme lors de la commande.
Une nouvelle CIT avec authentification forte obligatoire doit être envoyée en autorisation.
Pour les échéances suivantes (MIT):
- Méthode walletOrder : Vous conservez la nouvelle valeur du
champ
schemeTransactionIdentifier
dans votre système d'information pour initier les MIT. Il devient le nouvel identifiant de chaînage pour les transactions subséquentes - Méthode duplicate : Vous conservez le
schemeTransactionIdentifier
de la nouvelle CIT qui devient latransactionReference
pour les prochaines duplications.
Le STI n’est pas connu
Dans le cas où le schemeTransactionIdentifier
de la
transaction initiale (CIT) n'est pas connu car non restitué lors de la
prise de commande ou d'abonnement, différentes solutions sont possibles
selon la fonction utilisée.
Pour les paiements réalisés via la fonction walletOrder
Si le STI n’est pas restitué en réponse de la demande d’autorisation de la CIT, nous vous préconisons de faire comme suit :
- soumettre votre MIT sans valoriser le champ
initialSchemeTransactionIdentifier
dans la requête - stocker dans votre système d'information l’identifiant de chaînage
qui vous sera restitué dans le champ
schemeTransactionIdentifier
en réponse de la demande d’autorisation de cette MIT - valoriser le champ
initialSchemeTransactionIdentifier
de la requête avec ce même identifiant de chaînage pour les MIT suivantes
Pour les paiements réalisés via la fonction duplicate
Si en réponse de la duplication de la transaction initiale (CIT) le
champ initialSchemeTransactionIdentifier
n'est pas valorisé, cela signifie que la CIT n'avait pas d'identifiant de
chaînage associé.
Dans ce cas, nous vous préconisons de faire comme suit :
- Prendre comme référence de transaction la MIT créée suite à la
duplication de la CIT (
transactionReference
ous10TransactionId
) ; - Dupliquer cette première MIT pour effectuer les MIT suivantes.
Chainage sur plus de 18 mois
Mercanet stocke les transactions 18 mois dans le Back
Office. Ainsi dans le cas d’un chaînage sur une longue période (plus de 18
mois, cas des abonnements par exemple), la transaction initiale (CIT)
n’est plus accessible car purgée. Il n'est donc plus possible de récupérer
l'identifiant de chaînage (champ schemeTransactionIdentifier
) de
celle-ci.
Nous vous préconisons de faire de la duplication de proche en proche en
soumettant vos MIT en valorisant le champ initialSchemeTransactionIdentifier
dans la requête avec l’identifiant de chaînage de la dernière MIT réalisée
:
- Création CIT0
- Duplication CIT0 pour créer MIT1
- Duplication MIT1 pour créer MIT2
- Duplication MIT2 pour créer MIT3..