(Not Supported) 3DS 1.0 | Documentation CentralPay

L’objet enrollment permet de générer une transaction 3DS.

Les transactions en 3DS 1.0 ne sont plus préconisées à la faveur du 3DS 2.0.

l'arret du 3DS 1.0 aura lieu:

Pour les utilisateurs de VISA le 21 Octobre 2022.
Pour les utilisateurs de MASTERCARD le 14 Octobre 2022.

Les détenteurs de cartes peuvent procéder à des paiements sécurisés à l’aide du protocole 3D Secure (transaction dite à authentification forte). Le 3DS améliore la protection des marchands contre certains types de chargebacks. CentralPay fournit un service complet qui gère la fonctionnalité 3D Secure. Vous n'avez donc pas besoin d’avoir recours à un MPI externe.

Le processus de paiement des cartes 3D Secure commence de la même manière que les transactions régulières. Vous devez donc obtenir un cardTokenId ou utiliser un customerId existant. Cependant, avant l'étape du traitement de la transaction, obtenez préalablement des informations additionnelles.

Ainsi, vous devez :

Vérifier si la carte est 3D Secure ou non, soit en appelant le service "checkEnrollment", soit en parametrant une règle d'Acceptance qui réalisera le checkEnrollment pour vous et vous adressera le contenu de la réponse dans une requette HTTP 307.
Dans le cas où la carte est 3D Secure, vous devez obtenir certains paramètres (une payer Authentification Request ("Pareq") et l'URL vers le service d'authentification de l'émetteur du détenteur de carte).

Vos clients sont redirigés vers le site web de l’émetteur de carte pour vérifier leur identité en utilisant le protocole 3D Secure.

Vous recevez une confirmation, en d’autre terme une payment authentification Response "PaRes" à utiliser pour traiter la transaction.

A - Réaliser une transaction 3DS :

1Créer une carte (à l’aide des objets customer ou cardToken)

Créer un cardToken (également éventuellement créer un customer)
Ou utiliser un customerId existant

2Déterminer si la carte prend en charge ou nécessite une authentification 3D SECURE

Faites un checkEnrollment avec un cardTokenId ou customerId.
Gardez le champ enrollmentId pour un usage ultérieur.

3Rediriger le détenteur de carte vers ACS (cette action est effectuée par le commerçant)

En cas de succès, se munir de la requête d’authentification du payer, la Payer authentification Request "paReq" et de l’"acsURL" reçus lors du checkEnrollment et effectuer la redirection suivante :

<form id="downloadForm" name="downloadForm" method="POST" action="<ASC_bank_url>">
  <input type="hidden" id="PaReq" name="PaReq" value="<value_of_paReq>">
  <input type="hidden" id="TermUrl" name="TermUrl" value"="<return_merchant_url>">
  <input type="hidden" id="MD" name="MD" value="<merchant_description>">
</form>

[..] Ds

<script>
  document.getElementById("downloadForm").Submit();
</script>

Cette procédure permet d’afficher l’interface où le détenteur de carte peut saisir ses données personnelles.

4Obtenir des informations de l'ACS (cette action est effectuée par le commerçant)

Comme réponse de l'ACS, vous recevez le champ "paRes".

5Traiter la transaction sécurisée

Effectuez une transaction avec ces 2 champs supplémentaires "3ds [enrollmentId]" et "3ds [paRes]" :

La valeur du champ enrollmentId est obtenue à partir du checkEnrollment
La valeur du champ paRes est obtenue auprès de l'ACS

Remarque : toutes les fonctions utilisent le type "MIME" : "application/x-www-form-urlencoded".

B - Réaliser une transaction 3DS transaction avec une regle d'Acceptance

Une règle d'acceptance est une condition logique qui permet d'autoriser, de restreindre et / ou d'interdire des transactions.
Une règle est composée de 4 aspects: l'action, les attributs, les opérateurs et les valeurs.

Vous pouvez donc créer des regles très précises (montant, zone, cumul d'opérations, ... )qui déclencheront l'action de réaliser une transaction 3DS. Dans ce cas, la regle réalisera pour vous un "checkEnrollment" et vous adressera son résultat dans une requete HTTP 307. Le reste du processus suit l'exemple précédent.

Si une demande de transaction est retournée avec un code HTTP 307, vous avez donc tous les éléments de l'objet checkEnrollment nécessaires afin notamment de charger l'URL reçue dans le champ checkEnrollment.acsURLavec les paramètres POST suivants:

PaReq: utilisez la valeur de checkEnrollment.paReq.
MD: utilisez la valeur de checkEnrollment.merchantName.
TermUrl: l'URL qui sera chargée après validation 3DS, elle doit lire et gérer la réponse depuis la page banque 3DS.

Récupérez ensuite la réponse 3DS et effectuez une autre demande de transaction en ajoutant les paramètres suivants à la tentative précédente:

3ds [paRes] utilise la valeur de paRes de la réponse 3DS.
3ds [enrollmentId] utilise la valeur de checkEnrollment.enrollmentId de l'objet de transaction précédent.

Exemple de demandes de transaction après l'action du moteur de règles 3DS

Première demande de transaction:

curl -v https://test-api.centralpay.net/v2/rest/transaction \
-u 'DEMOPSC:eUZG&DVD6cCD' \
-d merchantTransactionId=00201806876 \
-d pointOfSaleId=95f83a22-e0a2-4a57-9457-6fcd8198b82b \
-d amount=2500 \
-d currency=EUR \
-d receiptEmail=john.doe@outlook.fr \
-d customerId=20f26fd6-56a2-492a-9a87-2603c9a77ca5 \
-d cardId=943ed87f-92c6-4546-a312-c187453a9a86 \
-d endUserIp=172.24.72.54 \
-d order[firstName]=JOHN \
-d order[lastName]=DOE \
-d order[country]=GB

Response après regle d'acceptance (HTTP response code 307):

{
  "checkEnrollment": {
    "enrollmentId": "d43fa45f-e7c3-4b40-a886-cffc76d56fa7",
    "creationDate": "2018-02-14T12:50:41.591+01:00",
    "additionalData": {},
    "acsURL": "https://test-threedsecure.centralpay.net/acs",
    "amount": 2500,
    "cardFingerprint": "b384a276872de0bc02bb858cab0a76d0dc9a607e",
    "currency": "EUR",
    "first6": "400000",
    "last4": "0002",
    "merchantCountry": "FR",
    "merchantName": "Live Demo",
    "merchantTransactionIdentifier": "180214125040048",
    "merchantURL": "https://centralpay.net",
    "paReq": "eJxVUttuwjAM/ZWq7yVJSUuL3CA... ...J+b6RfubH+fYVvye+/+Q==",
    "status": "SUCCESS"
  },
  "otp": false,
  "cvc": false
}

Demande de Transaction après un 3DS validé avec succès:

curl -v https://test-api.centralpay.net/v2/rest/transaction \ 
-u 'DEMOPSC:eUZG&DVD6cCD' \ 
-d merchantTransactionId=00201806876-#act \ 
-d pointOfSaleId=95f83a22-e0a2-4a57-9457-6fcd8198b82b \ 
-d amount=2500 \ 
-d currency=EUR \ 
-d receiptEmail=john.doe@outlook.fr \ 
-d customerId=20f26fd6-56a2-492a-9a87-2603c9a77ca5 \ 
-d cardId=943ed87f-92c6-4546-a312-c187453a9a86 \ 
-d endUserIp=172.24.72.54 \ 
-d order[firstName]=JOHN \ 
-d order[lastName]=DOE \ 
-d order[country]=GB \ 
-d 3ds[enrollmentId]=d43fa45f-e7c3-4b40-a886-cffc76d56fa7 \ 
-d 3ds[paRes]=eJydVlmzosgSfvdXnDjzaNvsKhPoRLEpss... ...mRz+79T1//eFx+PIif76GvD+W/AatUt1c=

Faites attention aux nouveaux champs 3ds [enrollmentId] et 3ds [paRes] ajoutés dans la deuxième demande de transaction et à la différence de valeur du champ merchantTransactionId:

Première demande de transaction: 00201806876.
Deuxième demande de transaction: 00201806876- # act.

La réponse de transaction retournée contiendra, entre autres, les détails suivants:

{
  "transactionId": "14b7b7ef-3411-495a-b322-d1a77520b848",
  "merchantTransactionId": "00201806876-#act",
  "creationDate": "2018-02-14T12:50:52.752+01:00",
  "totalAmount": 2500,
  "customerId": "20f26fd6-56a2-492a-9a87-2603c9a77ca5",
  "card": {
    "cardId": "943ed87f-92c6-4546-a312-c187453a9a86",
    "customerId": "20f26fd6-56a2-492a-9a87-2603c9a77ca5",
    "fingerprint": "b384a276872de0bc02bb858cab0a76d0dc9a607e"
  },
  "3ds": true,
  "endUserIp": "172.24.72.54",
  "receiptEmail": "john.doe@outlook.fr",
  "pointOfSaleId": "95f83a22-e0a2-4a57-9457-6fcd8198b82b",
  "enrollmentId": "d43fa45f-e7c3-4b40-a886-cffc76d56fa7",
  "additionalData": {}
}

C - Environnement 3DS de Test

Vous pouvez tester entièrement le processus 3D Secure dans notre environnement de test/sandbox.
Pour simuler une authentification 3D Secure avec la fonction checkEnrollment, utilisez les numéros de carte de crédit test.

Si vous souhaitez procéder à une simulation avec une carte non 3D Secure, vous pouvez utiliser les numéros de carte suivants : 4100000000000019 et 4100000000000027. L'API va retourner un message d’échec. Vous ne serez pas redirigé(e) vers la fenêtre d'authentification de l'ACS.