3DS1 et 3DS2 sont tous deux disponibles pour votre intégration de bout en bout des rendez-vous dans le Centre d'actions. Vous pouvez implémenter l'une de ces fonctionnalités (ou les deux) pour votre intégration.
3DS1 ou 3DS2 répond aux exigences de la norme PSD2 concernant l'authentification forte du client. Il existe toutefois quelques différences importantes:
- 3DS1: vous pouvez décider de déclencher 3DS1 pour une transaction lorsque vous avez des signaux indiquant que le débit est frauduleux.
- La mise en œuvre de 3DS1 nécessite que vous apportiez des modifications à votre serveur de réservation.
- 3DS2: 3DS2 n'est utilisé que pour les transactions auxquelles la directive PSD2 s'applique (la banque acquéreuse et la banque du client se trouvent dans l'EEE).
- Si vous mettez en œuvre 3DS2, vous devez modifier votre flux marchands.
Mise en œuvre de 3DS2
L'implémentation de 3DS2 nécessite l'ajout de champs supplémentaires à votre flux marchand dans le message TokenizationConfig. Si tous les paiements sont versés sur le même compte, vous devez répéter la valeur dans chaque entrée de marchand. Si les paiements sont versés sur différents comptes, les valeurs de chaque entrée de marchand devront correspondre au compte qui reçoit les fonds dans le cadre de la transaction.
Modifications apportées au flux des marchands
merchant_of_record_name: nom du marchand officiel. Ce nom visible par l'utilisateur sera affiché dans les défis 3DS2.payment_country_code: pays dans lequel la transaction sera traitée, au format ISO 3166-1 alpha-2.- Message
CardNetworkParameters: ce message est répété avec les valeurs spécifiques à différents réseaux (nécessaire uniquement pour Visa et American Express).card_network: réseau (Visa, American Express) auquel ces valeurs s'appliquentacquirer_bin: numéro d'identification bancaire de la banque acquéreuse utilisée pour le traitement de la carte.acquirer_merchant_id: l'identifiant du marchand attribué par l'acquéreur au marchand et utilisé dans le cadre de l'autorisation de transaction (pour les transactions Visa et American Express).
En ajoutant ces champs à votre flux marchand, vous recevrez un cryptogramme 3DS2 dans la unparsed_payment_method_token reçue par votre serveur de réservation chaque fois que la directive PSD2 s'applique à la transaction. Vous devez transmettre le unparsed_payment_method_token et son cryptogramme intégré à votre partenaire de traitement des données, conformément à ses spécifications.
Mise en œuvre de 3DS1
Modifications apportées au serveur de réservation
Nous allons envoyer une requête CreateBooking et, si vous estimez que 3DS1 est nécessaire pour la transaction, renvoyez un Booking Failure à partir de votre méthode CreateBooking et spécifiez PAYMENT_REQUIRES_3DS1 comme cause. Dans cette réponse d'échec, vous devez également spécifier le message ThreeDS1Parameters dans le message PaymentFailureInformation:
acs_url= URL à partir de laquelle charger un formulaire à présenter à l'utilisateur pour authentification.pa_req= une requête PaymentAuthentication. À publier dans le formulaire ACSUrl.transaction_id= un identifiant utilisé par le fournisseur ACS. À publier dans le formulaire ACSUrl.md_merchant_data= données que le Centre d'actions doit partager avec le fournisseur ACS, le cas échéant.
Nous renvoyons ensuite la requête CreateBooking d'origine avec le code pa_response situé dans le message PaymentInformation. Le champ pa_response contient la charge utile qui nous est renvoyée par un fournisseur ACS. Vous devez l'utiliser pour autoriser la transaction avec votre sous-traitant.
Voici un diagramme décrivant le processus 3DS1 :
