3DS1 et 3DS2 sont tous deux disponibles pour votre intégration de la fonctionnalité Réservations de bout en bout d'Actions Center. Vous pouvez mettre l'un ou l'autre en œuvre dans votre intégration (ou les deux).
3DS1 et 3DS2 répondent tous deux aux exigences SCA (Strong Customer Authentication) de la directive DSP2. Il existe cependant quelques différences importantes:
- 3DS1: vous pouvez décider de déclencher 3DS1 pour une transaction lorsque vous recevez des indicateurs 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 est utilisé seulement pour les transactions auxquelles la directive DSP2 s'applique (autrement dit, dans les cas où 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
La mise en œuvre de 3DS2 nécessite que vous ajoutiez des champs supplémentaires à votre flux marchands dans le message TokenizationConfig. Si tous les paiements sont versés dans le même compte, vous devez répéter la valeur dans chaque entrée marchand. Si les paiements sont versés dans des comptes différents, les valeurs dans chaque entrée marchand doivent correspondre au compte recevant 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, que l'utilisateur peut voir, sera affiché dans les challenges 3DS2.payment_country_code: pays dans lequel la transaction sera traitée, au format ISO 3166-1 alpha-2.- Message
CardNetworkParameters: ce message répété inclut des valeurs propres à chaque réseau (nécessaire uniquement pour Visa et American Express).card_network: le réseau (Visa, American Express) auquel ces valeurs s'appliquent.acquirer_bin: le numéro d'identification bancaire de la banque acquéreuse utilisée pour le traitement de la carte.acquirer_merchant_id: la référence marchand attribuée par l'acquéreur au marchand à utiliser lors de l'autorisation de la transaction (pour les transactions Visa et American Express).
Le fait d'ajouter ces champs à votre flux marchands vous permet de recevoir un cryptogramme 3DS2 dans le jeton unparsed_payment_method_token reçu par votre serveur de réservation chaque fois que la directive DSP2 s'applique à la transaction. Vous devez transmettre le jeton unparsed_payment_method_token et son cryptogramme intégré à votre partenaire de traitement des paiements conformément à ses spécifications.
Mise en œuvre de 3DS1
Modifications apportées au serveur de réservation
Nous envoyons une requête CreateBooking et si vous estimez que 3DS1 est requis pour la transaction, nous renvoyons un Booking Failure à partir de votre méthode CreateBooking, en spécifiant 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 il est possible d'importer 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 destinées à Actions Center à partager avec le fournisseur ACS, le cas échéant.
Nous renvoyons ensuite la requête CreateBooking d'origine avec la réponse pa_response située 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 partenaire de traitement des paiements.
Voici un diagramme décrivant le processus 3DS1 :
