Paybox 3DSv2

[Cerdic]

Il semble donc qu'on ne soit pas à jour sur la 3DSv2 et il faudrait envoyer des paramètres en plus d'après la doc

Une nouvelle variable permet au marchand d’exprimer, en fonction de son évaluation de la
transaction concernée, une opinion sur la réalisation d’un chalenge lors de l’authentification
du porteur.

Attention : Pour que cette variable soit prise en compte il est nécessaire que
le passage en version CB2A 1.6. soit traité entre Verifone et votre banque.

Cette variable sera remontée à la banque du porteur qui pourra ou non la prendre en
compte pour décider de la méthode d’authentification à employer.

Attention : Dans le cas où le marchand exprime le souhait de ne pas avoir
de chalenge et que ce souhait est respecté par la banque ; il n’y a pas de
transfert de responsabilité et le risque de fraude restera sous la responsabilité
du marchand.

Dans une implémentation de Paybox System la variable est nommée :
PBX_SOUHAITAUTHENT

Dans une implémentation de Paybox Direct la variable est nommée :
ChallengeIndicator

Les valeurs possibles pour ces variables sont :

• 01 Pas de préférence
• 02 Pas de chalenge demandé
• 03 Chalenge souhaité
• 04 Chalenge requis

Remarque : Cette variable est facultative

Lorsque la variable n’est pas valorisée ; la valeur 01 (Pas de préférence) sera
envoyée par défaut.

Attention : Dans certains cas, concernant essentiellement les paiements
récurrents, la plateforme Verifone forcera le souhait d’authentification à 04
pour permettre le traitement de la tentative de paiement.

[Cerdic]

3.4 PAIEMENTS RECURRENTS

Les versions de protocoles actuellement implémentées permettent de conserver les
implémentations actuelles sans modification pour la réalisation de paiements récurrents.

Attention : Les versions de protocoles actuelles ne pourront pas être
conservées sur le long terme.

Les évolutions apportées au paiement récurrent requièrent une authentification forte du
porteur de carte. Cette authentification sera réalisée lors de la première transaction et une
référence sera conservée et transmise pendant les échéances suivantes

Pour les marchands utilisant la solution Paybox System, la plateforme Verifone sera en
mesure de rassembler les informations nécessaires et aucune modification de
l’implémentation n’est à prévoir.

Dans le cas d’une implémentation de la solution Paybox Direct, certaines informations
doivent être ajoutées à votre appel pour que le contexte de l’authentification soit connu et
puisse être traité par la banque du porteur de carte.

Les paramètres permettant de transmettre ces données sont décrits et identifiés comme
conditionnels dans le 5.2.2 Données à ajouter – Remote MPI.

[Cerdic]

4.3 MODIFICATIONS A APPORTER

Ces modifications concernent uniquement l’implémentation du 3D-Secure v2.
Cette nouvelle version permet l’exploitation de davantage d’informations pour ne pas
challenger systématiquement le porteur via l’application de sa banque ou précédemment
l’envoi d’un SMS.

La transmission de ces nouvelles informations obligatoires se fera spécifiquement via les
deux nouvelles variables PBX_SHOPPINGCART et PBX_BILLING décrites dans les
paragraphes suivants.

L’ajout de variables facultatives permettra d’améliorer le scoring de la demande
d’authentification et donc le nombre d’authentification réalisées sans chalenge par la banque
émettrice (frictionless).

PBX_SHOPPINGCART

Format : XML. Obligatoire.

Cette variable contient une seule donnée obligatoire pour des raisons protocolaires ; le
nombre d’articles constituant la commande.

Il sera nommé <totalQuantity> et sera valorisé dans un champ numérique allant de 1 à 99

Exemple

<?xml version="1.0" encoding="utf-8"?>
<shoppingcart>
<total>
<totalQuantity>15</totalQuantity>
</total>
</shoppingcart>

PBX_BILLING

Format : XML. Obligatoire.

Les informations concernant le porteur de carte et son adresse de facturation.

Attention : Pour transporter des caractères accentués ou autres caractères
spéciaux, il sera nécessaire de les encoder en UTF8.

Exemple

<?xml version="1.0" encoding="utf-8"?>
<Billing>
<Address>
<FirstName>Jean</FirstName>
<LastName>Dupont</LastName>
<Address1>12 rue Paul Dautier</Address1>
<ZipCode>78140</ZipCode>
<City>Velizy-Villacoublay</City>
<CountryCode>250</CountryCode>
</Address>
</Billing>

[Cerdic]

Pour les autres trucs qu'on peut aussi ajouter mais pas indispensable cf la doc technique
https://www.paybox.com/wp-content/uploads/2022/03/ManuelIntegrationPaybox_DSP2_FR-v1.9.pdf

Presta paybox à mettre à jour donc...

[rastapopougros]

Du coup si je comprends bien, dans le lot, envoyer les infos de facturations dont une adresse, c'est obligatoire ? Donc il faut renseigner ces infos (bien découpées) dans le pipeline fourni pour les infos du payeur ?

Et pour pas détecter trop tard, est-ce que du coup bank pourra faire une erreur dès le form de paiement si on détecte que ya pas tous les infos nécessaires, pour le voir dès le SPIP, avant tout envoi ailleurs ?

C'est bizarre car il me semblait avoir vu des sites qui vendaient du pas physique (billet par ex) et qui ne demandaient jamais d'adresse, mais j'ai peut être mauvaise mémoire ou bien c'était ya longtemps et maintenant changé.

[Cerdic]

Oui... mais non.

Il faut envoyer ces infos autant que possible pour éviter de déclencher une demande d'authentification renforcée lors du paiement. Autrement dit, si tu connais l'adresse tu la renseignes et c'est mieux pour la banque. Mais aussi ce faisant tu files plein d'infos à tous ceux qui sont sur la chaine de paiement, donc bon, c'est moins bien pour la vie privée.

De fait tous les prestas ont implémentés un moyen de renseigner les infos personnelles des acheteurs, et ça alimente soit disant une "évaluation du risque sur le paiement" via une boite noire dans la banque (ou chez le fournisseur de cartes peut-être), qui décide alors de déclencher l'authentification renforcée pour sécuriser le paiement, ou que non, ça va pas de risque ici on peut accepter le paiement sans être pénible.

Mais donc en amont la boutique peut choisir de demander ou non ces infos, et de les filer ou non à la banque lors du paiement, c'est un choix technico/politico/commercial.

Bref, il y a donc le pipeline dans bank pour faire ça
https://github.com/nursit/bank/blob/master/inc/bank.php#L424
et a priori le minima a fournir serait le nom+prénom+email mais on va pas déclencher des erreurs dans le plugin parce qu'il manque des choses ou non (à la limite on pourrait loger pour informer le webmestre).

A noter que du point de vue du droit français tu es censé faire une facture avec une adresse et pas seulement un nom, donc tu dois théoriquement toujours savoir plus que le nom. J'ai fait des boutiques où on se contentait du nom + email, je sais pas si c'est 100% ok du point de vue du droit pour les factures. D'autant que le nom n'est même pas vérifié, tu te fies à ce que l'internaute veut bien remplir.

Mais donc en conclusion, la conséquence finale c'est juste qu'il va sans doute devoir payer avec authentification forte plus souvent...

Cela dit, ça n'empêche que les banques demande maintenant que tu envoies des paramètres en plus avec ces infos, même si certaines peuvent rester vides parce que tu les connais pas (ou tu veux pas les donner).

[rastapopougros]

Ah mais je disais ça parce qu'il semblait avoir compris que c'était obligatoire… Donc dans ce cadre si, ça aurait été mieux qu'on le sache dans SPIP en amont bien affiché si pas remplis.

Mais si tu dis que non c'est pas obligatoire, qu'on peut laisser vide (et juste ça va du coup forcer à faire une double auth banque à chaque fois) bah aucun problème : moi perso je préfère ne rien donner comme infos, et toujours devoir retaper un code, que ce soit avec sms ou boitier donné par la banque, si ça permet de moins faire balader mes infos.

[Cerdic]

C'est intégré, on devrait être bon sur paybox

[jmoupah]

Salut,

une cliente a reçu un recommandé du Crédit Agricole indiquant que 3DSv2 sera obligatoire à partir du 30 septembre, les paiements sans les deux nouvelles variables PBX_SHOPPINGCART et PBX_BILLING seront refusés. Je ne sais pas comment c'est chez les autres banques.

La v6 est compatible mais la mise à jour n'est pas visible via SVP car elle est en test, donc certain·es risques d'avoir de mauvaises surprises en octobre.

Est-ce que la v6 est assez stable (comme laisse penser 612ee97) pour changer de statut ou pas encore ?

[Cerdic]

la v6 est bien testée maintenant donc je pense qu'on est bon, je l'ai passée en stable cf ffcab4d

Je veux bien un retour de confirmation que le 3DSv2 marche bien avec paybox avec cette version, car je n'avais pas pu tester toute la chaine de paiement !

[jmoupah]

Ca semble fonctionner de mon côté (4 paiements ok depuis la mise à jour, pas d'erreur).
Merci :)