Documentation du guide d'intégration des logiciels 3D Secure
Guide d'intégration 3D Secure
À partir du 01.01.2021, l'authentification à deux facteurs sera mise en œuvre comme une exigence obligatoire pour toutes les transactions de paiement par carte de commerce électronique. Afin de se conformer à cette obligation, le
les opérateurs de réseaux de cartes de crédit utiliseront la procédure dite 3D Secure. Pour vous en tant que commerçant, il est obligatoire de pouvoir effectuer cette procédure pour vos clients à partir de
01.01.2021. Vous trouverez ci-dessous une description des différents modes d'intégration et de la manière dont la procédure 3D Secure doit être mise en œuvre pour eux.
Veuillez sélectionner la méthode d'intégration que vous utilisez
- Utilisez-vous le formulaire de paiement hCO ?
- Utilisez-vous le formulaire de paiement hPF?
- Traitez-vous les paiements sans utiliser un formulaire fourni par le système Unzer?
Veuillez noter: Il est également important de savoir de quelle manière les prélèvements ou les préautorisations (réservations) sont effectués. Même si vous utilisez un formulaire de paiement d'Unzer GmbH pour l'enregistrement des données de la carte, le processus 3D Secure sera effectué sans formulaire de paiement lors du premier débit ou de la première autorisation des données de la carte. Dans ce cas, la troisième voie d'intégration sans formulaire fourni par Unzer s'applique.
Veuillez noter également :
Si vous utilisez des paiements récurrents (paiements d'abonnement), assurez-vous de lire la section «3D Secure et Paiements récurrents».
Procédure 3D Secure lors de l'utilisation du formulaire de paiement hCO
Le formulaire de paiement hCO est déjà conçu pour la procédure 3D Secure. Aucune action supplémentaire de votre part n'est nécessaire pour la mise en œuvre de la procédure. Cependant, vous
devez vous assurer que votre système peut traiter les réponses correspondantes de notre système de paiement au cas où le processus 3D Secure serait lancé. Dans la réponse asynchrone du
système de paiement à votre serveur, le résultat de la transaction est transmis et doit y être évalué avant un retour URL est transmis au système de paiement.
Pour cela, les paramètres suivants doivent être évalués.
- TRAITEMENT.CODE.RETOUR = 000.200.000
- PROCESSING.RETURN = Transaction + en attente
- TRAITEMENT.RESULTAT = ACK
Explication : Le statut de la transaction est « en attente », le paramètre PROCESSING.RESULT
ne représente qu'un résultat préliminaire. Tant que le processus 3D Secure est effectué, le statut
rester en suspens.
Le résultat final de la transaction est alors soit
- TRAITEMENT.CODE.RETOUR = 000.000.000
- TRAITEMENT.RESULTAT = ACK
or - TRAITEMENT.CODE.RETOUR = irgendein Wert ungleich 000.000.000 ou 000.200.000
- TRAITEMENT.RESULTAT = NOK
Dans le premier cas, la transaction a été réalisée avec succès, dans le second cas, elle a échoué globalement. Ce dernier peut avoir diverses raisons, dont un refus d'authentification. Vous serez
recevoir des informations plus détaillées dans les paramètres «PROCESSING.RETURN» et «PROCESSING.RETURN.CODE».
Nous vous recommandons d'exécuter un test pour les deux messages. Pour plus d'informations sur la façon de faire un test et les détails de la carte de crédit que vous pouvez utiliser pour un test, veuillez voir ci-dessous.
Procédure 3D Secure lors de l'utilisation du formulaire de paiement hPF
Le formulaire de paiement hPF est également conçu pour utiliser déjà la procédure 3DS. Aucune action supplémentaire de votre part n'est nécessaire pour la mise en œuvre de la procédure. Comme décrit
pour la mise en œuvre de hCO la réponse du système de paiement se fait en deux étapes, c'est pourquoi votre système doit vérifier la valeur du PROCESSING.RETURN.CODE
paramètre lors du traitement de la réponse.
Pour cela, les paramètres suivants doivent être évalués.
- TRAITEMENT.CODE.RETOUR = 000.200.000
- PROCESSING.RETURN = Transaction + en attente
- TRAITEMENT.RESULTAT = ACK
Explication: Le statut de la transaction est «en attente», le paramètre PROCESSING.RESULT ne représente qu'un résultat préliminaire. Tant que le processus 3D Secure est effectué, le statut
rester en suspens.
Le résultat final de la transaction est alors soit
- TRAITEMENT.CODE.RETOUR = 000.000.000
- TRAITEMENT.RESULTAT = ACK
or - TRAITEMENT.CODE.RETOUR = irgendein Wert ungleich 000.000.000 ou 000.200.000
- TRAITEMENT.RESULTAT = NOK
Dans le premier cas, la transaction a été réalisée avec succès, dans le second cas, elle a échoué globalement. Ce dernier peut avoir diverses raisons, dont un refus d'authentification. Vous serez
recevoir des informations plus détaillées dans les paramètres «PROCESSING.RETURN» et «PROCESSING.RETURN.CODE».
Nous vous recommandons d'exécuter un test pour les deux messages. Pour plus d'informations sur la façon de faire un test et les détails de la carte de crédit que vous pouvez utiliser pour un test, veuillez voir ci-dessous.
Procédure 3D Secure avec connexion directe
Si vous n'utilisez pas un formulaire de paiement fourni par Unzer (anciennement heidelpay) pour traiter les paiements par carte de crédit, ou si vous enregistrez simplement une carte en utilisant l'un des formulaires et traitez la préautorisation (réservation) ou le débit comme référence à l'enregistrement en tant que communication directe avec le système de paiement, vous devez mettre en œuvre le processus 3D Secure.
Flux de transaction asynchrone:
Il s'agit d'un processus asynchrone dans lequel votre serveur reçoit un transfert URL (Réorienter URL) de notre système de paiement. Votre serveur doit rediriger le client vers ce URL afin qu'il puisse effectuer l'authentification via la procédure 3D Secure. Le résultat de cette authentification 3D Secure est signalé directement à Unzer par la banque émettrice de la carte.
Après une authentification réussie, la transaction est traitée dans le système Unzer de la manière que vous connaissez déjà en envoyant à votre système un résultat global à la fin, auquel vous répondez
avec une redirection URL. Le système de paiement redirigera alors le client vers votre système en utilisant cette redirection URL de votre système
Remarque : Dans ce workflow, votre système reçoit deux réponses du système de paiement :
- Un avec le statut «en attente» (PROCESSING.RETURN.CODE = 000.200.000 et PROCESSING.RETURN = Transaction + en attente) et les paramètres de redirection vers la banque émettrice de la carte du client
– Un avec le résultat final du débit ou de la réservation. Il y a aussi deux redirection URLest mentionné dans ce processus, celui du système de paiement vers lequel le client doit être redirigé pour s'authentifier auprès de la banque émettrice de sa carte et celui de votre système, lors de la réception du résultat final, pour rediriger le client dans votre système.
Les modifications suivantes seront apportées à la procédure régulière. Veuillez noter qu'en raison de la mise en œuvre d'autres méthodes de paiement asynchrones, telles que Paypal, certaines de ces
des processus peuvent déjà exister dans votre implémentation.
- Réponse URL
Lors du premier appel (n ° 2 sur le schéma) au système de paiement, une «Réponse URL”Doit être passé dans le groupe frontend.
Veuillez noter: Le paramètre IDENTIFICATION.REFERENCEID n'est pertinent que si vous faites référence à une inscription ou à une autre transaction déjà existante - Traitement de la redirection URL Si une authentification est requise, une redirection URL et d'autres paramètres du groupe de redirection sont transférés dans la réponse du système de paiement (n ° 5 sur le schéma).
- Renvoi du client vers la redirection URL
Si le groupe de redirection répond par une redirection URL, le navigateur du client doit être redirigé vers ce URL (N° 6 sur le schéma) pour effectuer l'authentification. Les paramètres supplémentaires du groupe de redirection doivent être transférés vers le website en tant que paramètres POST.
Remarque: les paramètres supplémentaires sont renvoyés dans le groupe «PROCESSING.REDIRECT.xxx» uniquement avec 3D Secure Version 1 (même là, le nombre et la dénomination peuvent varier), alors qu'avec 3D Version 2 seul un PROCESSING.REDIRECT.URL comme affiché ci-dessous est renvoyé : https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF/run Cela signifie que quel que soit le type et le nombre de paramètres, le navigateur client doit rediriger vers le PROCESSING.REDIRECT.URL.
Ci-dessous vous trouverez un code simple example de la façon dont une telle redirection peut être exécutée. Les partie est destinée à informer les clients finaux dont les systèmes ne prennent pas en charge Javascript ou l'ont désactivé. Nous vous recommandons fortement d'effectuer la redirection dans la fenêtre de navigateur active du client et de ne pas utiliser de fenêtres contextuelles ou de nouvelles fenêtres de navigateur, car cela pourrait
irriter les clients et les amener à fermer la page vers laquelle ils sont redirigés.
- Contrôle des résultats asynchrone
Le résultat de l'authentification est envoyé de manière asynchrone à votre serveur. Le système de paiement attend un URL comme réponse. (N ° 12 et 13 sur le schéma). Pour réussi ou rejeté
paiements, un autre URL peut être répondu ici par votre système. - Chemin de retour du client
Le système de paiement redirige le client vers le URL fournis par le système du commerçant une fois le processus d'authentification et la transaction de paiement terminés.
Remarque: les étapes 4.) et 5.) se déroulent exactement de la même manière que vous connaissez déjà dans les transactions NONE 3D Secure existantes.
Paiement 3D sécurisé et récurrent
A partir du 1er janvier 2021, 3D Secure sera obligatoire pour toutes les transactions par carte e-commerce. Cependant, comme cela n'est guère applicable pour les paiements récurrents, la banque
les systèmes ont un flux de travail séparé pour cela.
A cet effet, les banques distinguent entre
- CIT = transactions initialisées par le client
- MIT = transactions initialisées par le commerçant
La première transaction d'une carte dans votre compte marchand doit être authentifiée avec 3D Secure à partir du 01.01.2021. Une telle authentification réussie est une exigence obligatoire dans
afin de pouvoir soumettre ultérieurement d'autres réservations sur la même carte sans 3D Secure. Le client doit donc être redirigé vers la banque émettrice de sa carte pour le premier débit en
conformément à la procédure décrite ci-dessus et s'y authentifier en tant que titulaire de la carte. Si un débit n'est pas prévu au moment de la commande, par example en raison d'une période d'essai, une réservation (pré-autorisation) d'au moins un euro doit être effectuée auprès de 3D Secure en présence du client. La capture de cette réservation n'est pas nécessaire.
Pour les clients existants, cependant, aucune authentification 3D Secure n'a besoin d'être établie. Si le premier débit réussi a eu lieu avant le 01.01.2021, l'enregistrement client peut également être considéré comme
ont été authentifiés avec succès. Pour les nouveaux clients à partir du 01.01.2021, en revanche, l'authentification 3D Secure est obligatoire pour le premier prélèvement ou réservation (pré-autorisation).
Attention : à cet égard, le système bancaire examine les données de la carte, pas les données du client. Ainsi, si un client existant utilise une nouvelle carte après le 01.01.2021, par ex.ample parce que le précédent
l'un a expiré ou parce qu'il a changé de banque émettrice de carte, il s'agit d'un nouveau cycle récurrent du point de vue des banques view et doit être authentifié avec 3D Secure pour la première réservation.
Une fois cette première authentification effectuée avec succès, toutes les transactions ultérieures sont exonérées de l'obligation d'utiliser 3D Secure Les prérequis pour un paiement récurrent sans 3D Secure sont donc :
- Il y a au moins un débit ou une réservation (pré-autorisation) réussie qui a été soit effectuée avec 3D Secure, soit a eu lieu avant le 01.01.2021.
- il est référencé à un enregistrement existant et débité lors de la soumission
Pour informer le système de paiement qu'il s'agit d'un paiement récurrent, le paramètre RECURRENCE.MODE=REPEATED doit également être envoyé. Cela signale au système qu'un
le paiement récurrent doit être signalé aux systèmes bancaires.
Attention: Si le paramètre RECURRENCE.MODE = REPEATED est saisi lors du premier chargement d'une nouvelle carte, le transfert 3D Secure sera effectué malgré ce paramètre.
Test de l'implémentation 3D Secure
Vous pouvez tester la connexion 3D Secure à tout moment via notre système de paiement. Pour ce faire, utilisez le mode « CONNECTOR_TEST » pour une transaction, comme indiqué dans l'examples ci-dessus.
Données de connexion pour ce test:
| SÉCURITÉ. | 31HA07BC8142C5A171745D00AD63D182 |
| UTILISATEUR EN LIGNE | 31ha07bc8142c5a171744e5aef11ffd3 |
| UTILISATEUR.PWD | 93167DE7 |
| TRANSACTION.CANAL | 31HA07BC8142C5A171749A60D979B6E4 |
| Devises configurées pour la version 3D 2 | EUR, USD, SEK |
| Devises configurées pour la version 3D 1 | GBP, CZK, CHF |
Le point de terminaison de la passerelle système est soit
Passerelle SGW:
- https://test-heidelpay.hpcgw.net/sgw/gtw - encodé en Latin-15
- https://test-heidelpay.hpcgw.net/sgw/gtwu - encodé en UTF-8
Passerelle NGW:
– https://test-heidelpay.hpcgw.net/ngw/post
Données de carte de crédit pour ce test:
| marques | numéros de carte | CVV | date d'expiration | note |
| MasterCard | 5453010000059543 | 123 | date ultérieure | 3D – mot de passe : secret3 |
| Visa | 4711100000000000 | 123 | date ultérieure | 3DS – mot de passe : secret !33 |
Attention : Pour 3D Secure Version 2, vous n'avez pas besoin de saisir de mot de passe, mais cliquez simplement sur le lien « Cliquez ici pour terminer l'authentification.
La seule façon de simuler une erreur avec 3D Secure Version 2 est de laisser la page avec le lien expirer (environ 18 minutes).
En savoir plus sur ce manuel et télécharger le PDF :
Documents / Ressources
 |
Guide d'intégration des logiciels 3D Secure [pdf] Documentation Unzer, Guide d'intégration, 3D Secure |
