1. Home
2. Solutions d'intégration
3. Intégrations
4. Page de paiement hebergée

1. Introduction

Notre Page de paiement hebergée est la solution idéale pour permettre à vos clients d’effectuer des paiements sur votre boutique en ligne. Il s’agit d’une solution tout-en-un aux exigences minimales suivantes :

• Elle est sécurisée : adoptez un profil bas PCI en externalisant la gestion de données sensibles sur notre plateforme !
• Elle est flexible : adaptez notre page de paiement grâce aux nombreuses possibilités à des fins d’adaptation visuelle !
• Elle répond aux attentes des clients : permettez à vos clients de choisir parmi les différents modes de paiement les supports de notre plateforme!
  
  

Ce schéma vous donne un aperçu des parties impliquées et de leurs responsabilités dans le processus de paiement :

Avant de traiter des transactions en ligne, n’hésitez pas à utiliser notre environnement de test pour découvrir notre solution sans frais ni aucun engagement ! Lorsque vous voulez mettre votre page en ligne, découvrez ici comment obtenir un compte d’exploitation ou contactez-nous !

2. Pour commencer

Pour traiter des transactions sur notre plateforme avec la Page de paiement hebergée, assurez-vous :

• De disposer d’un compte d’exploitation sur notre plateforme
• De répondre aux exigences PCI
• D’avoir au moins un mode de paiement activé sur votre compte (vérifiez dans Configuration > Payment methods)
• Votre boutique en ligne est hébergée sur un serveur qui permet la notification de formulaires HTML. Si vous ne souhaitez pas développer vous-même de logiciels, consultez nos Plugins et extensions. Chacune de ces solutions à part entière vous aidera à démarrer rapidement !

3. Intégrer à la Page de paiement hebergée

Le canal de notre Page de paiement hebergée vous permet de traiter des transactions pour l’ensemble de nos modes de paiement. Découvrez ici comment cela fonctionne et ce que vous devez faire.

Comprendre le flux des paiements

Le schéma décrit toutes les étapes d’une transaction type sur laPage de paiement hebergée :

1. Votre client se rend sur vos pages de paiement et finalise l’achat sur votre page de paiement.
2. Vous envoyez la demande de paiement sans les informations relatives à la carte de crédit à votre URL de destination sur la Page de paiement hebergée comprenant un ensemble de paramètres obligatoires/recommandés/facultatifs. De cette façon, votre client est également redirigé vers notre Page de paiement hebergée.

• Nous récupérons le modèle pour adapter la présentation de laPage de paiement hebergée (facultatif).

3. Votre client saisit les informations relatives à sa carte de crédit sur notre Page de paiement hebergée sécurisée.

• Nous procédons à une vérification en matière de fraude grâce à nos outils dédiés à la fraude (facultatif).

4. Nous redirigeons le client vers sa banque émettrice à des fins d’authentification 3-D Secure.
5. Le titulaire de carte s’identifie. Notre système reçoit le résultat de la part de l’émetteur.
6. Sur la base de ce résultat, il y a deux scénarios possibles :

• En cas d’échec de l’identification, nous redirigeons le titulaire de la carte vers le DECLINEURL, ce qui met fin au flux. Vous recevez le résultat via les canaux de retour d’information de commerce en ligne.
• En cas de réussite de l’identification, nous soumettons la transaction financière en question à l’acquéreur pour qu’il traite la transaction.

7. Nous vous envoyons le résultat du paiement. En fonction du résultat de l’acquéreur, nous redirigeons le titulaire de la carte vers l’ACCEPTURL, le DECLINEURL ou l’EXCEPTIONURL. Vous recevez le résultat via les canaux de retour d’information de commerce en ligne.
8. En cas de réussite de la transaction, vous pouvez fournir les biens ou services.

Cibler les URL de destination en test/ligne

Notre plateforme vous permet d’envoyer des demandes de nouvelles transactions soit sur notre Environnement de test soit sur notre Environnement de production

URL de destination : TEST	https://ogone.test.v-psp.com/ncol/test/orderstandard_utf8.asp
URL de destination : EN LIGNE	https://secure.ogone.com/ncol/prod/orderstandard_utf8.asp

Pour les transactions test, sans impact financier, utilisez l’URL-TEST. Les transactions seront envoyées vers notre environment de test, de ce fait, vers votre compte test. Pour les transactions réelles, avec un impact financier, utilisez l’URL-PRODUCTION. Les transactions seront envoyées vers notre environment en ligne, de ce fait, vers votre compte en ligne. Assurez-vous d’être passé sur l’URL-LIVE dès que vous avez terminé vos tests.

Envoyer la demande de transaction

Une fois l’achat finalisé par votre client sur votre page de paiement pour le règlement effectif, votre serveur fait une demande HTTP POST.

Envoyez la demande vers l’URL de destination de la Page de paiement hebergée  comprenant un ensemble de paramètres obligatoires/recommandés/facultatifs et redirigez, en parallèle, votre client vers cette URL.

Une demande habituelle se présente comme suit :

<form method="post" action="https://ogone.test.v-psp.com/ncol/test/orderstandard_utf8.asp" id=form1 name=form1>

<!-- general parameters: see Form parameters -->
<input type="hidden" name="PSPID" value="">
<input type="hidden" name="ORDERID" value="">
<input type="hidden" name="AMOUNT" value="">
<input type="hidden" name="CURRENCY" value="">
<input type="hidden" name="LANGUAGE" value="">
<input type="hidden" name="CN" value="">
<input type="hidden" name="EMAIL" value="">
<input type="hidden" name="OWNERZIP" value="">
<input type="hidden" name="OWNERADDRESS" value="">
<input type="hidden" name="OWNERCTY" value="">
<input type="hidden" name="OWNERTOWN" value="">
<input type="hidden" name="OWNERTELNO" value="">

<!-- check before the payment: see Security: Check before the payment -->
<input type="hidden" name="SHASIGN" value="">
<!-- layout information: see Look and feel of the payment page -->
<input type="hidden" name="TITLE" value="">
<input type="hidden" name="BGCOLOR" value="">
<input type="hidden" name="TXTCOLOR" value="">
<input type="hidden" name="TBLBGCOLOR" value="">
<input type="hidden" name="TBLTXTCOLOR" value="">
<input type="hidden" name="BUTTONBGCOLOR" value="">
<input type="hidden" name="BUTTONTXTCOLOR" value="">
<input type="hidden" name="LOGO" value="">
<input type="hidden" name="FONTTYPE" value="">

<!-- post payment redirection: see Transaction feedback to the customer -->
<input type="hidden" name="ACCEPTURL" value="">
<input type="hidden" name="DECLINEURL" value="">
<input type="hidden" name="EXCEPTIONURL" value="">
<input type="hidden" name="CANCELURL" value="">
<input type="submit" value="" id=submit2 name=submit2>

</form>
    

Envoyer des paramètres obligatoires/recommandés/facultatifs

Vous devez inclure un ensemble de paramètres pour chaque transaction. Vous trouverez des informations détaillées (courte description, format, longueur maximale, etc.) pour chaque paramètre dans notre Parameter Cookbook.

Voici les paramètres obligatoires, recommandés et facultatifs pour une demande de transaction type :

Paramètres obligatoires

Paramètre	Description / Valeurs possibles
PSPID	The name of your account on our platform to which you send the transaction request.
ORDERID	A unique order number for each request. The parameter ORDERID is used to check whether requests are accidentally sent twice to our platform. If two transactions with the same value for ORDERID are sent within 45 days, we will block the second transaction. This check applies only if the first transaction’s PAYIDSUB has reached one of the following statuses: 2 5 9  Consequentially, an ORDERID can be used only once within 45 days. After that period, ORDERIDs already sent can be re-used
AMOUNT	Amount to be paid by your customer Multiply the amount by 100 as this parameter must not contain any decimals or other separators Example: If the order is 12,34 €, you need to send AMOUNT=1234
CURRENCY	Currency of the amount in ISO 4217 format (ie EUR, GBP etc.)
LANGUAGE	The language our Page de paiement hebergée is displayed to your customer. The value is a combination of ISO 639-1 (language) and ISO 3166-1 (country) Examples: en_US fr_FR Find a full list of all language we support in our Parameter Cookbook.
SHASIGN	Unique character string for order data validation. It is used to make sure that the transaction request is indeed from your server and has not been manipulated by an unauthorised third party.   Learn here to learn how to construct it.

Paramètres recommandés

EMAIL	Your customer’s address / contact data
OWNERADDRESS
OWNERZIP
OWNERTOWN
OWNERCTY
OWNERTELNO
TP PMLISTTYPE	Modify the look and feel of the Page de paiement hebergée Learn here how to do it

Paramètres optionels

COMPLUS	Fields to send any additional data you would like to receive in the transaction feedback Learn here to learn how to use them
PARAMPLUS
PM	Make specific payment methods (un)available on the Page de paiement hebergée or redirect your customers directly to third-party payment method services (ie. Paypal, iDEAL etc.) Learn here how to use them
BRAND
PMLIST
EXCLPMLIST
CREDITDEBIT
OPERATION	Override the default operation code in your Back Office for each transaction  Learn here how to use it
USERID	Link transactions to a specific user in your data bases Learn here how to use it
ACCEPTURL DECLINEURL  EXCEPTIONURL CANCELURL HOMEURL  CATALOGURL  BACKURL	URLs to receive transaction feedback and to redirect your customers depending on the outcome Learn here to learn how to use them

Calculez la valeur SHASIGN

Composante à part entière, le flux de transactions consiste à veiller à ce que les transactions envoyées à notre plateforme soient légitimes.

Pour empêcher qu’un tiers non autorisé manipule l’une de vos demandes de transaction, nous utilisons une méthode à la fois sûre et facile à mettre en œuvre pour vous : en envoyant le paramètre SHASIGN. Le SHASIGN est une chaîne de caractères unique qui peut être créée par deux parties uniquement : vous et Worldline.

La chaîne est basée sur les données envoyées associées aux paramètres de sécurité et de la transaction dans votre Back Office. Ces paramètres sont uniquement accessibles par vous et Worldline. Pour chaque transaction, notre système recréera la chaîne envoyée dans SHASIGN. Si les deux chaînes correspondent, notre plateforme considère la transaction comme étant légitime et la traitera.

Créer la valeur pour SHASIGN en suivant ces règles :

1. Liez l’ensemble des paramètres/valeurs pour former une seule chaîne selon cette méthode :

Nom de paramètre + = + valeur de paramètre + phrase de passe SHA-IN

Veillez à :

• Utiliser la phrase de passe SHA-IN tel qu’indiqué dans votre Back Office dans Configuration > Technical Information > Checks for e-Commerce & Alias Gateway > SHA-IN pass phrase.
• Inclure tous les paramètres (et uniquement ceux-là) pris en compte par notre système et les trier par ordre alphabétique tel que mentionné sur cette liste.
• Normaliser les données (c’est-à-dire supprimer les espaces avant et après).
• N'envoyez pas de paramètres vides : inclure uniquement les paramètres spécifiques à votre mode d'intégration avec les valeurs associées.

Par exemple (avec les paramètres obligatoires uniquement) :

Paramètres de la demande de transaction :

_{AMOUNT=1500 (15.00 x100)
CURRENCY=EUR
LANGUAGE=en_US
ORDERID=1234
PSPID=MyPSPID}

Phrase de passe SHA-IN tel qu’indiqué dans le Back Office

_{Mysecretsig1875!?}

Chaîne liée :

_{AMOUNT=1500Mysecretsig1875!?CURRENCY=EURMysecretsig1875!?LANGUAGE=en_USMysecretsig1875!?
ORDERID=1234Mysecretsig1875!?PSPID=MyPSPIDMysecretsig1875!?}

2. Hâchez la chaîne liée selon la méthode de hachage sélectionnée dans votre Back Office dans Configuration > Technical Information > Global security parameters > Hash algorithm.

Résultat du condensé (selon la méthode SHA-1) :

_{F4CC376CD7A834D997B91598FA747825A238BE0A}

3. Envoyez votre demande de transaction, y compris le condensé, dans le paramètre SHASIGN.

Paramètres de la demande de transaction :

_{AMOUNT=1500 (15.00 x100)
CURRENCY=EUR
LANGUAGE=en_US
ORDERID=1234
PSPID=MyPSPID}

_{SHASIGN=F4CC376CD7A834D997B91598FA747825A238BE0A}

Dès que nous recevons une demande de transaction, nous recalculons la chaîne en fonction des paramètres que vous avez envoyés et de la phrase de passe SHA-IN / méthode de hachage tel que stipulé dans votre Back Office.

Si nous obtenons la même valeur que celle que vous avez envoyée, nous redirigerons votre client vers notre Page de paiement hebergée, afin qu’il saisisse les informations relatives à sa carte de crédit.

En cas de non-concordance, nous redirigeons le client vers une page d’erreur, annulant la transaction.

Pour résoudre ce type de problème de transactions, consultez le Back Office dans Configuration > Error, où nous enregistrons ce type de transactions comme « commande inconnue ». Notre système y affichera le SHASIGN que vous avez envoyé et celui que notre système a créé. Cela vous permettra de modifier votre calcul de SHASIGN. Notre guide de Dépannage vous fournira davantage d’informations quant à la résolution de ce problème. 

N’incluez pas de paramètres vides dans la chaîne liée. Utiliser des lettres majuscules pour les noms des paramètres Décoder à partir de l’URL la valeur de hachage avant que vous calculiez le hachage Tous les caractères de la chaîne liée doivent être en majuscules. Bien que nous prenions en charge les méthodes de hachage SHA-1/SHA-256/SHA-512, nous recommandons d’utiliser SHA-256 ou SHA-512. Cela garantira une sécurité maximale pour le processus de vérification. Pour plus de sécurité, nous vous demandons d’utiliser des phrases de passe SHA différentes dans nos Environnement de test and Environnement de production.

Définir les paramètres du Back Office

Pour traiter les transactions avec succès, vous devez également définir certains paramètres dans votre Back Office. Ils se trouvent dans différents onglets sous Configuration > Technical information.  

Voici les paramètres obligatoires, recommandés et facultatifs :

Paramètres obligatoires

Module Back Office	Description/Fonction
Global Security parameters > Hashing method > Hash algorithm	Définissez la méthode de hachage pour la chaîne liée afin de calculer la valeur SHASIGN.
Data and origin verification > Checks for e-Commerce & Alias Gateway > SHA-IN pass phrase	Définissez la phrase de passe SHA-IN qui est ajoutée à la chaîne liée afin de calculer la valeur SHASIGN.

Paramètres recommandés

Module Back Office	Description/Fonction
Global transaction parameters > Payment retry	Les tentatives de demande par transaction que vous concédez à vos clients pour finaliser avec succès leur paiement. Après l’échec de la dernière tentative, la transaction atteint le statut 2.
Global transaction parameters > Processing for individual transactions	Notre plateforme vous propose de chronométrer les demandes de paiement que nous envoyons à nos acquéreurs de trois manières différentes. Sélectionnez celle qui correpond le mieux à votre modèle commercial : Always online (Immediate): nous envoyons la transaction juste après avoir reçu votre demande. En cas d’indisponibilité de l’acquéreur, la transaction atteint le statut 2. Approprié pour les biens/services que vous devez livrer juste après l’achat. Online but switch to offline when the online acquiring system is unavailable: ): nous envoyons la transaction juste après avoir reçu votre demande. Si l’acquéreur est indisponible, nous tenterons de la récupérer en la renvoyant ultérieurement. Approprié pour les biens/services pour lesquels le délai entre l’achat et la livraison est acceptable. Always offline (Scheduled):  : nous envoyons la transaction à certaines heures (environ 4 heures après vous l’avoir envoyée). Comme votre client n’aura pas à attendre le résultat en temps réel, l’achat est finalisé plus rapidement qu’avec les autres méthodes. Par conséquent, vous et votre client recevez un état final de la transaction avec un retard de plusieurs heures. Approprié pour les biens/services pour lesquels le délai entre l’achat et la livraison est acceptable.
Transaction feedback > eCommerce > HTTP redirection in the browser	Définissez les URL vers lesquelles vos clients sont redirigés en fonction du résultat. Pour en savoir davantage, consultez notre chapitre consacré à ce sujet.
Transaction feedback > eCommerce > Direct HTTP server-to-server request	Définissez les URL et le moment où vous souhaitez recevoir un retour d’information sur les transactions. Pour en savoir davantage, consultez notre chapitre consacré à ce sujet.
Transaction feedback > eCommerce > Dynamic e-Commerce parameters	Sélectionnez les paramètres que vous souhaitez inclure dans le retour d’information sur les transactions. Pour en savoir davantage, consultez notre chapitre consacré à ce sujet.
Transaction feedback > eCommerce > All transaction submission modes > Security for request parameters	Définissez une SHA-OUT pass phrase pour valider la provenance du retour d’information sur les transactions. Pour en savoir davantage, consultez notre chapitre consacré à ce sujet.
Transaction feedback > eCommerce > All transaction submission modes > HTTP request for status changes	Définissez l’URL et le moment où vous souhaitez recevoir un retour d’information sur les changements de statut des transactions après l’achat initial. Pour en savoir davantage, consultez notre chapitre consacré à ce sujet.

Paramètres optionels

Module Back Office	Description/Fonction
Global transaction parameters > Default operation code	Indiquez si notre plateforme doit traiter vos transactions comme des autorisations (statut 5) ou des ventes directes (statut 9) au moment de la demande. En savoir plus dans notre chapitre consacré à ce sujet.
Global transaction parameters > Default data capture (payment) procedure	Définissez la méthode et le moment pour capturer les transactions de statut 5. En savoir plus dans notre chapitre consacré à ce sujet.
Payment page > Cancel button	Faites apparaître/disparaître un bouton sur notre Page de paiement hebergée pour permettre à vos clients d’annuler la transaction.
Payment page > Back button redirection	Définissez l’URL vers laquelle vos clients sont envoyés en cliquant sur le bouton « Retour » sur notre Page de paiement hebergée.
Payment page > General terms and conditions	Faites apparaître un lien vers vos conditions générales sur notre Page de paiement hebergée.
Transaction e-mails > E-Mails to the merchant	Précisez si vous souhaitez recevoir des e-mails de notre système pour les transactions traitées. En savoir plus dans notre chapitre consacré à ce sujet.
Transaction e-mails > E-mails to the customer	Indiquez si vos clients doivent recevoir des e-mails de notre système pour les commandes traitées. En savoir plus dans notre chapitre consacré à ce sujet.

4. Personnaliser la présentation de la page de paiement

Notre plateforme vous permet d’adapter, dans une large mesure, la présentation de notre Page de paiement hebergée . Adapter la page de paiement à votre image de marque invitera vos clients à finaliser leur commande après avoir été redirigés vers la Page de paiement hebergée.

Consultez nos recommandations pour optimiser votre entreprise.

Découvrez ici comment utiliser cette fonctionnalité et les multiples façons d’améliorer l’expérience de paiement de vos clients.

L’utilisation de notre plateforme pour héberger les modèles ne modifiera pas votre niveau PCI. Si vous décidez d’héberger vous-même le modèle, vous devrez peut-être vous conformer à un niveau PCI supérieur. Veuillez contacter votre acquéreur pour obtenir plus d’informations.

Utiliser le modèle de Page de paiement adaptée d’Worldline

La façon la plus simple de modifier notre Page de paiement hebergée est d’utiliser notre modèle de Page de paiement adaptée (RPP). Ce modèle est idéal pour une expérience d’achat en ligne multi-écrans pour vos clients. Il vous assure une conversion optimisée à la fois sur un ordinateur de bureau et un appareil mobile.

Pour vous permettre de démarrer facilement et de découvrir toutes ses possibilités, nous vous fournissons un modèle de démonstration complet. Pour l’utiliser, suivez les étapes suivantes :

1. Téléchargez le fichier compressé.
2. Connectez-vous au Back Office. Allez dans Configuration > Template > Template selection > eCommerce payment page et cliquez sur « ACTIVATE».
3. Allez dans Configuration > Template > File Manager > Upload Template Files. Téléchargez l’ensemble du contenu du fichier compressé. Après quelques minutes, notre système a validé les fichiers (dans « Uploaded Files», ils apparaissent comme « Validated » dans le colonne « Status »). À présent, ils sont prêts à être utilisés sur notre Page de paiement hebergée.
4. Allez dans Configuration > Template > Template selection > eCommerce payment page. Sélectionnez le fichier HTML « IngenicoResponsivePaymentPageTemplate_index.html » dans le menu déroulant « Default merchant template ».
   

Pour notre modèle de Page de paiement adaptée, vous devez organiser l’affichage des modes de paiement de manière verticale. Pour ce faire, vous devez envoyer le paramètre supplémentaire PMLISTTYPE=2 pour chaque transaction. Nous vous recommandons de limiter la taille de votre logo à 300 px aussi bien pour la largeur que la hauteur. Cela garantira un temps de chargement minimal sur les appareils mobiles.

Créer différents modèles de Page de paiement adaptée

Notre plateforme vous permet également de modifier le fichier de démonstration à votre guise et ainsi de créer vous-même des modèles à partir de rien, ainsi que de concevoir des modèles à utiliser en fonction d’événements particuliers, comme le Black Friday ou la période des fêtes de fin d’année ou bien...

Pour ce faire, tenez compte des éléments suivants :

• Fichier HTML : la base pour chaque modèle (tout comme « IngenicoResponsivePaymentPageTemplate_index.html » du fichier de démonstration).
  Vous pouvez créer votre page de modèle comme vous le souhaitez. Il faut juste qu’elle contienne la chaîne de caractères génériques « $$$PAYMENT ZONE$$$ » :
  
  

<html>$$$PAYMENT ZONE$$$</html>

Cet emplacement est réservé aux champs dans lesquels vos clients saisissent les données de leur carte de crédit. Vous pouvez modifier les éléments dans cet espace à l’aide d’un fichier CSS.
Vous pouvez inclure les types de fichiers suivants dans votre modèle : .css, .jpg, .jpeg, .gif, .png, .html, .js.
Utilisez « $$$TP RESOURCES URL$$$/[nom de votre fichier] » pour les mentionner dans votre fichier.

<html><head>        <link rel=”stylesheet” type=”text/css” href=”$$$TP RESOURCES URL$$$/yourFile.css”>        <script scr=”$$$TP RESOURCES URL$$$/test.js”></script></head><body><div>$$$PAYMENT ZONE$$$</div></body></html>

Veillez à télécharger tous les fichiers de référence dans le Back Office via Configuration > Template > File Manager > Upload Template Files.

N’utilisez pas les balises BASE, les cadres ou les balises FORM pour encapsuler la chaîne $$$PAYMENT ZONE$$$.

Fichier CSS : vous pouvez utiliser des feuilles de style pour adapter à la fois vos éléments dans le fichier HTML et l’espace réservé aux champs dans lesquels vos clients saisissent les données de leur carte de crédit. Pour adapter ces dernières, nous avons défini une classification pour les différents éléments de cet espace. Vous devez ajouter le bloc de code suivant entre les balises <head></head> et modifier les propriétés de ces catégories pour qu’elles s’adaptent à la présentation de votre site :

<style type="text/css"><!--td.ncolh1 {background-color : #006600; color : yellow; font-family : verdana}td.ncoltxtl {background-color : #ffffcc; color : black; text-align : right; font-weight : bold}td.ncoltxtl2 {background-color : #ffffcc; color : black; text-align : right; font-weight : bold}td.ncoltxtr {background-color : #ffffcc; color : black; text-align : left; font-weight : bold}td.ncoltxtc {background-color : #ffffcc; color : black; text-align : center; font-weight : bold}td.ncolinput {background-color : #ffffcc; color : black}td.ncolline1 {background-color : #ffffff; color : black}td.ncolline2 {background-color : #ffffcc; color : black}
input.ncol {background-color : #006600; color : white}td.ncollogoc {background-color : #ffffcc; color : black; text-align : center; font-weight : bold}table.ncoltable1 { background-color: #ffffcc; }table.ncoltable2 { background-color: #ffffcc; border-width : medium; border-color : green; }table.ncoltable3 { background-color: #ffffcc; }--></style>

Ces captures d’écran de l’écran de sélection des paiements, du formulaire de paiement et de la page de résultat montrent quels éléments exactement vous pouvez modifier avec les propriétés. 

Comme avec le fichier HTML, vous pouvez mentionner les fichiers dans votre CSS. À la place de « $$$TP RESOURCES URL$$$/[nom de votre fichier] », il vous suffit d’utiliser « ./[nom de votre fichier] ».

Veillez à respecter la syntaxe définie des feuilles de style en cascade. Testez votre CSS sur plusieurs navigateurs, car la manière dont ils gèrent le style peut varier.

Créer des modèles mobiles

Bien que le modèle de Page de paiement adaptée convienne à tous les appareils, nous vous proposons également des fichiers spécifiques afin d’améliorer l’expérience de paiement sur les appareils mobiles. Consultez la version d’origine et la version « basique ». Vous pouvez télécharger ces deux versions ici.

Ces deux versions ont pour base un fichier HTM nommé respectivement « StandardMobileTemplate » et « StandardMobileTemplate_Generic ».  Contrairement au modèle standard de Page de paiement adaptée, il s’agit d’une combinaison d’un fichier HTML et CSS. Les propriétés du fichier CSS se répartissent comme suit 

Exemple de capture d’écran	Propriétés
L’en-tête de la page de paiement :	.securedBG{background: #797979;}.secured{padding: 8px 20px 0px 40px;color: #ffffff;width: 235px;margin: 0 auto;background: url("lock.png") 5px no-repeat #797979; height: 30px; }- Order Summarytable.ncoltable1{width: 100%;margin: 0 auto;min-width: 300px !important;}td.ncoltxtl{font-family: open-sans ,Verdana,sans-serif;font-size: 14px;background-color:#ffffff;text-align : left !important;font-weight : bold !important;vertical-align:bottom;}td.ncoltxtr{text-align: left;font-weight: normal;font-family: open-sans ,Verdana,sans-serif;font-size: 14px;background-color:#ffffff;}
La section des informations relatives au paiement : les clients saisissent les détails de leur carte de crédit.	td.ncolinput{text-align: left;font-weight: normal;font-size: 14px;font-family: open-sans ,Verdana,sans-serif; display: block;box-shadow: none !important;}input.ncol{background-color: #ffffff;height: 40px;font-size: 14px;text-align: center;padding: 0px;font-family: open-sans ,Verdana,sans-serif;margin: 0 35px 20px;border-bottom: 1px solid #999999;border-radius: 0px;-webkit-appearance: none !important;-webkit-border-radius: 0 !important;}td.ncoltxtl2{text-align: left;font-family: open-sans ,Verdana,sans-serif;white-space: nowrap;display: block; font-size: 14px;background-color:#ffffff;}
Le pied de la page de paiement :	td.ncollogoc{text-align: center;font-weight: normal;font-size: 14px;padding: 2px;vertical-align: top !important;}td.ncollogoc IMG{width: 90px;height: 55px;margin-right: 4px;}.ncollogoc td .ncol{width: auto;padding-right: 10px;padding-left: 10px;cursor:pointer;}.ncollogoc input.ncol{margin-top:10px !important;-webkit-appearance: none !important;-webkit-border-radius: 0 !important;}
La page d’état des paiements : vos clients sont redirigés après la validation des données de la carte de crédit :	td.ncoltxtc{background-color:#ffffff;color:#999999;padding: 0px;text-align: left;font-weight: normal;font-size: 14px;border-top: 0px solid #ffffff;font-family: open-sans ,Verdana,sans-serif;}td.ncoltxtc h3</code{text-align: center;font-weight: normal !important;padding: 5px;font-family: open-sans ,Verdana,sans-serif;}td.ncoltxtmessage{background-color: #ffffff;color: #999999;text-align: left;font-weight: normal;}

Utiliser plusieurs modèles

Vous pouvez télécharger plusieurs modèles vers le Back Office et vous en référer pour chaque transaction.

Par défaut, le modèle sélectionné dans le Back Office dans Configuration > Template > Template selection > eCommerce payment page > du menu déroulant « Default merchant template » sera utilisé pour chaque transaction. Toutefois, vous pouvez passer outre ce paramètre en envoyant un paramètre supplémentaire avec votre demande de transaction.

Paramètre	Description / Valeurs possibles
TP	By sending the file name of any of your HTML files uploaded in the Back Office (Configuration > Template > File Manager > Uploaded files), you can select a specific template for the transaction Example: “myTemplate.html”

 

Utiliser un modèle dynamique

Notre plateforme vous permet également d’adapter notre Page de paiement hebergée en hébergeant un modèle sur votre propre serveur.

La création du fichier HTML/CSS suit le même processus que celui décrit dans le chapitre précédent. Cependant, étant donné que vous ne téléchargez pas le modèle dans le Back Office, mais que vous l’hébergez sur votre serveur, il y a quelques différences.

• Pour que notre système charge le modèle à partir de votre serveur, vous devez envoyer un paramètre supplémentaire pour toutes vos demandes de transaction :

Paramètre	Description / Valeurs possibles
TP	The URL of the dynamic template page The URL must be absolute (contain the full path) and cannot be relative. Do not specify any ports in your URL, we only accept ports 443 and 80. Any component included in the template page must also have an absolute URL.

• Bien que vous puissiez utiliser la même page de modèle pour toutes les commandes (ou la modifier en envoyant le paramètre TP), votre demande peut la générer de façon dynamique en fonction des paramètres de la commande. Pour ce faire, utilisez un modèle d’URL fixe qui renvoie à un résultat émanant du numéro de commande. Notre système ajoute les principales données de paiement, y compris le numéro de référence de la commande du commerçant, lorsqu’il récupère la page de modèle :

HTTP request = url_page_template?ORDERID=...&AMOUNT=...&CURRENCY=…

Si vous décidez d’héberger vous-même le modèle, vous devrez peut-être vous conformer à un niveau PCI supérieur. Veuillez contacter votre acquéreur pour obtenir plus d’informations. Le chargement du modèle à partir de votre serveur prenant plus de temps que depuis le nôtre, le processus de paiement global est plus long. Notre système est configuré avec un délai d’attente de 5 secondes pour la demande de récupération du modèle dynamique. Contactez notre service d’assistance pour modifier le temps d’attente. Si l’un de vos éléments utilisés sur la page du modèle dynamique n’est pas hébergé sur un serveur sécurisé, la plupart des navigateurs ne reconnaîtront pas la connexion à notre plateforme comme étant sécurisée. Par conséquent, nous vous encourageons vivement à héberger tous vos fichiers sur un serveur sécurisé.

Autoriser le contrôle de sécurité pour le modèle

Afin de protéger vos clients contre la fraude, nous avons mis en place plusieurs contrôles de sécurité pour le modèle.

Connectez-vous au Back Office et allez dans Configuration > Template > Advanced configuration. Vous pouvez adapter les paramètres suivants :

• Global > Enable JavaScript check on template
  Une fois activés, notre plateforme vérifie si JavaScript est utilisé sur la page de modèle. Si JavaScript est détecté, nous bloquerons le modèle et utiliserons un modèle par défaut à la place.
• Dynamic template 

Si vous sélectionnez « Yes » pour « Allow usage of dynamic template », vous devez configurer un ou plusieurs noms de sites Internet sécurisés qui hébergent le modèle dynamique. Si vous en saisissez plusieurs, séparez-les par un point-virgule (« ; »). Veillez à ajouter le chemin d’accès complet du domaine URL (les sous-répertoires où se trouve le modèle peuvent être omis).
Pour chaque transaction, notre système compare la valeur envoyée dans le paramètre TP avec les noms des sites Internet configurés dans le Back Office. En cas de non-concordance, nous bloquons le modèle dynamique et téléchargeons à la place un modèle que vous avez chargé dans le Back Office. Si vous n’avez téléchargé aucun modèle, notre système chargera un modèle par défaut à la place. 

5. Rediriger les clients après leurs achats

Une fois que votre client a saisi les détails de sa carte de crédit, nous envoyons les données à l’acquéreur pour validation. Dès que nous recevons le résultat, nous redirigeons votre client sur une page de votre choix.

Pour chaque scénario, vous pouvez définir une autre URL. Calculez la valeur SHASIGN

Deux options s’offrent à vous pour définir ces URL :

1. Via le Back Office, allez dans Configuration > Technical Information > Transaction feedback > eCommerce > HTTP redirection in the browser.  Entrez une URL dans le champ correspondant au scénario :

Champ	Description
Accepturl	Transactions réussies (statut 5, 41 or 9)
Declineurl	Transactions refusées (statut 2)
Exceptionurl	Transactions annulées (statut 1)
Cancelurl	Transactions dont le résultat est incertain (statut 51 or 92)

2. Envoyez les paramètres supplémentaires suivants pour chaque demande de transaction :

Paramètre	Description / Valeurs possibles
ACCEPTURL	Transactions réussies (statut 5, 41 or 9)
DECLINEURL	Transactions refusées (statut 2)
CANCELURL	Transactions annulées (statut 1)
EXCEPTIONURL	Transactions dont le résultat est incertain (statut 51 or 92)

Si vous avez défini des URL tel qu’indiqué dans l’option 1 et que vous envoyez également des valeurs pour les paramètres comme décrit dans l’option 2, les URL dans le Back Office seront écrasées par les valeurs des paramètres. Si l’une de vos URL n’est pas conforme au protocole HTTPS, mais uniquement au protocole HTTP, votre client peut recevoir une alerte de son navigateur lorsqu’il entre dans un environnement non sécurisé. Dans ce cas, nous pouvons afficher une notification destinée à vos clients juste avant qu’ils soient redirigés. Activez-la dans le Back Office via Configuration > Technical Information > Transaction feedback > eCommerce > HTTP redirection in the browser en indiquant « I would like Worldline to display a short text to the customer on the secure payment page if a redirection to my website is detected immediately after the payment process.»

Si vous ne choisissez aucune de ces options, nous redirigeons alors vos clients vers l’une de nos pages de résultats génériques. Les pages indiqueront les résultats dans la langue correspondante que vous avez envoyés avec le paramètre LANGUE (c’est-à-dire « Autorisé » pour le statut 5).

Vous pouvez ajouter un catalogue et/ou une URL d’accueil sur notre page de résultats vers laquelle vous pouvez rediriger votre client.  Pour cela, vous devez envoyer les paramètres suivants avec la demande de transaction :

Paramètre	Description / Valeurs possibles
CATALOGURL	URL of your catalogue   If sent, a “Back to our catalouge” button will be visible on our generic result page
HOMEURL	URL of your home page   If sent, a “Back to merchant site” button will be visible on our generic result page   Can also be defined in the Back Office via Configuration > Technical Information > Payment page > Back button redirection, but will be overwritten if you send this parameter If you send the value "NONE", the button is not displayed

6. Obtenir un retour d’information sur les transactions

Pour suivre les résultats des transactions, notre plateforme offre plusieurs possibilités pour envoyer un retour d’information à votre serveur. Vous pouvez utiliser ces informations pour accéder à la transaction ultérieurement afin d’effectuer plus tard des opérations de maintenance (à savoir un remboursement).

Sélectionner les paramètres de retour d’information

En fonction de la configuration requise de votre base de données, vous pouvez définir exactement le type d’informations que vous souhaitez recevoir. Comme nous envoyons le retour d’information par paramètre, vous pouvez les sélectionner librement dans le Back Office :

• Allez dans Configuration > Technical Information > Transaction feedback > eCommerce > Dynamic e-Commerce parameters.
• Déplacez les paramètres que vous souhaitez recevoir dans le retour d’information de la rubrique « Available » à la rubrique « Selected ». Les paramètres suivants seront toujours inclus dans le retour d’information et ne peuvent être désactivés :

NCERROR

PAYID

ORDERID

STATUS

Calculer la valeur SHASIGN pour les demandes de retour d’information

De la même manière que nous validons les demandes de votre serveur, vous pouvez également valider l’origine de notre retour d’information.

Pour s’assurer de la validité du retour d’information reçu et qu’il ne constitue pas une intrusion d’une tierce partie, nous vous proposons d’envoyer un condensé basé sur les paramètres envoyés dans le retour d’information. En recalculant vous-même ce condensé sur la base de ces paramètres, vous pouvez facilement vérifier la validité du retour d’information.

Le mode de calcul de ce condensé suit le même principe que celui décrit dans ce chapitre. Comme il y a quelques différences, consultez le résumé suivant de toutes les étapes :

1. Le retour d’information que votre serveur reçoit comprend un paramètre nommé SHASIGN, qui inclut le condensé.

Pour recalculer le condensé, liez l’ensemble des paramètres/valeurs pour former une seule chaîne selon cette méthode.

Nom de paramètre + = + valeur de paramètre + phrase de passe SHA-OUT

Veillez à :

• Utiliser la phrase de passe SHA-OUT tel qu’indiqué dans votre Back Office dans Configuration > Technical Information > Transaction feedback > All transaction submission modes > SHA-OUT pass phrase.
• Inclure tous les paramètres (et uniquement ceux-là) pris en compte par notre système et les trier par ordre alphabétique tel que mentionné sur cette liste de paramètres SHA-OUT séparée.

2. Hâchez la chaîne liée selon la méthode de hachage sélectionnée dans votre Back Office dans Configuration > Technical Information > Global security parameters > Hash algorithm.
   
   
3. Comparez votre résumé avec celui que nous vous avons envoyé. S’ils correspondent, vous avez la confirmation que le retour d’information reçu est valide.

Cette fonction est facultative, car la demande au serveur est une boucle fermée avec des niveaux de sécurité supplémentaires (filtres TLS/HTTPS/IP sur votre serveur. Pour cela, veuillez consulter notre documentation sur le pare-feu). Si vous souhaitez continuer à utiliser cette fonctionnalité, assurez-vous de configurer une phrase de passe SHA-OUT. Sinon, nous n’enverrons pas de résumé dans le retour d’information.

Obtenir un retour d’information

Après avoir sélectionné les paramètres de retour d’information et défini un SHA-OUT, vous êtes prêt à recevoir un retour d’information. Notre plateforme vous propose deux options :

1. Recevoir un retour d’information sur les URL de redirection : dès que vos clients se retrouvent sur l’une de ces URL, nous envoyons une demande GET en conséquence. Pour utiliser cette option, signalez-le dans Configuration > Technical Information > Transaction feedback > eCommerce > HTTP redirection in the browser :

Cette option ne fonctionnera que si vos clients ferment leur navigateur une fois la redirection terminée. Pour ne pas dépendre du comportement de vos clients, nous vous proposons une deuxième option telle que stipulée ci-dessous.

 2. Recevoir un retour d’information de serveur à serveur : vous pouvez définir des URL distinctes et choisir une tranche horaire pour obtenir le retour d’information. Pour utiliser cette option, allez dans Configuration > Technical Information > Transaction feedback > eCommerce > Direct HTTP server-to-server request. Paramétrez les éléments suivants :

Timing of the request Always deferred (not immediately after the payment). Online Online but switch to a deferred request when the online requests fail.	Obtenir un retour d’information 10 minutes après l’achat Tout de suite après l’achat Juste après l’achat ou 10 minutes après l’achat en cas d’échec du premier transfert de retour d’information
If the payment's status is "accepted", "on hold" or "uncertain".	Obtenir un retour d’information pour les transactions qui se retrouvent dans le statut 5/9 ou 51/91 sur une URL de votre choix.
If the payment's status is "cancelled by the client" or "too many rejections by the acquirer".	Obtenir un retour d’information pour les transactions qui se retrouvent dans le statut 1 ou 2  sur une URL de votre choix.
Request method	Obtenir un retour d’information sous GET ou POST.

 

Pour vous assurer que votre serveur accepte notre retour d’information, veillez à configurer correctement votre pare-feu. Pour les options de délai « Always deferred» et « Online but switch to a deferred request […] », notre plateforme tentera à quatre reprises de vous envoyer le retour d’information si nous ne sommes pas en mesure de le faire en premier lieu. Pour des raisons de sécurité, nous vous recommandons de sélectionner POST plutôt que GET.

Obtenir un retour d’information pour les changements de statut ultérieurs

Dans certains cas, le statut de vos transactions changera à un moment ultérieur après le premier achat. Pour obtenir un retour d’information pour lesdits changements de statut « offline », allez dans Configuration > Technical Information > Transaction feedback > All transaction submission modes > HTTP request for status change. Paramétrez les éléments suivants :

Timing of the request Only at the time of the order authorisation request For each offline status change (payment, cancellation, etc.).	Obtenir un retour d’information Pour les transactions avec le statut initial 5 ou 51/52 Pour les transactions avec l’un des premiers statuts suivants: 5 / 51 / 52 91 / 92 61 / 62 81 / 82 91 / 92
URL on which the merchant wishes to receive a deferred HTTP request, should the status of a transaction change offline.	Obtenir le retour d’information sur une URL de votre choix

Renvoyer un retour d’information

Dans certains cas, une demande de redirection / retour d’information n’est pas effectuée correctement. Cela peut arriver, par exemple, si vos clients cliquent sur le bouton « retour » sur leur navigateur. Afin d’éviter toute confusion du côté de vos clients et de vous assurer que vous recevez bien le retour d’information, allez dans Configuration > Technical Information > Transaction feedback > General et indiquez « I would like Worldline to re-launch the "end of transaction" (post-payment request/redirection) process if required. » Cela garantira que :

• vos clients se retrouvent sur la bonne URL de redirection après leur achat.
• vous recevez le retour d’information sur vos URL.

7. Paiement sécurisé avec 3-D Secure

Pour votre client, une partie importante du flux de traitement des transactions est la vérification 3-D Secure (3DS). Vous n’avez rien de particulier à faire, si ce n’est activer 3DS pour toutes vos méthodes de paiement par carte. Nous nous chargeons du reste.

À la suite de l’introduction de 3DSv2, de nouvelles règles sont d’application. Nous collectons pour vous toutes les données pertinentes pendant le processus de paiement, mais vous pouvez toujours rendre l’approche 3DSv2 plus efficace en matière d’évaluation des risques en envoyant des paramètres supplémentaires (recommandés /optionels) avec la transaction.

PSD2 améliore la transparence du processus de paiement pour vous et vos clients. Ceci est particulièrement utile lorsqu’il s’agit de transactions de statut. Notre paramètre de retour d’information CH_AUTHENTICATION_INFO vous fournit des informations détaillées sur les émetteurs lorsqu’ils refusent des transactions de vos clients. Partagez ces informations avec vos clients afin de leur permettre de comprendre pourquoi leur banque a refusé leur transaction.

Pour recevoir CH_AUTHENTICATION_INFO dans vos URL de redirection, sélectionnez ce paramètre dans le Back Office via Configuration > Information technique > Retour d'information sur la transaction > Paramètres dynamiques du commerce en ligne. Cela permettra également de s’assurer que ces informations apparaissent dans l’aperçu des transactions via Opérations > Gestion transactions / Historique financier.
Comme vous ne recevrez pas les informations suffisamment tôt pour modifier, en conséquence, vos URL de redirection une fois la transaction finalisée, nous vous recommandons de marquer « Je veux que Worldline affiche, sur la page de paiement, un message court à l’attention du client lorsqu'une redirection vers votre site est détectée juste après le processus de paiement." dans le Back Office via Configuration > Information technique > Retour d'information sur la transaction > Redirection HTTP dans le navigateur. Notre plateforme redirigera ensuite vos clients vers notre page de résultats intermédiaires présentant les informations avant que vos clients ne se retrouvent au final sur vos URL de redirection.

7.1 Exclusions de la règle 3DSv2

Certaines transactions sont exclues de la SCA. Si l’une de vos transactions en fait partie, 3-D Secure ne sera pas mis en œuvre. Pour plus d’informations concernant quels types de transactions en font partie, consulteze notre guide consacré à ce sujet ici. 

Vous pouvez demander à éviter 3-D Secure de deux manières

1. Authentification en sélectionnant les valeurs appropriés pour paramètres Mpi.threeDSRequestorChallengeIndicator et 3DS_EXEMPTION_INDICATOR
   

   Paramètre	Valeurs
   Mpi.threeDSRequestorChallengeIndicator	Longueur : 2 caractères Type de données : chaîne Valeurs acceptées : 01 = pas de préférence 02 = pas de procédé d’identification demandé - utilisez cette valeur pour les transactions dont le montant est peu élevé (inférieur à 30 euros) 03 = procédé d’identification demandé : préférence du marchand 04 = procédé d’identification demandé : Obligatoire - utilisez cette valeur lorsque vous établissez une transaction récurrente avec votre client ou lorsque vous réessayez la transaction après un refus révocable (soft decline) 05 = pas de procédé d’identification demandé [l’analyse de risque de la transaction est déjà réalisée] utilisez cette valeur si votre acquéreur a accepté de vous accorder l’exemption ART 07 = pas de procédé d’identification demandé [SCA déjà réalisé] utilisez cette valeur lorsque vous réalisez le SCA de votre côté, doit être approuvé par votre acquéreur
   3DS_EXEMPTION_INDICATOR	Longueur : 2 caractères Type de données : chaîne Valeurs acceptées : 03 = TRA* de l’émetteur 04 = Exception pour faible montant (inférieur à 30 euros) 05 = ART* du commerçant/de l’acheteur 06 = Liste blanche 07 = Entreprise 08 = Expédition retardée 09 = Authentification déléguée (portefeuille certifié) * Transaction risk analysis (Analyse du risque de transaction)

   Vérifiez le fichier journal d’authentification ans le Back Office et recherchez le « TransStatus = I » pour voir si l’émetteur a accordé l’exemption. Cependant, vous ne bénéficierez plus du renversement de responsabilité en cas de transaction frauduleuse

2. Autorisation en sélectionnant les 3DS_EXEMPTION_INDICATOR and FLAG3D appropriés
   Pour contourner totalement 3-D Secure, envoyez les paramètres suivants :
   

   Paramètre	Valeurs
   FLAG3D	N = Ignorer le processus d’authentification 3DS
   3DS_EXEMPTION_INDICATOR	Longueur : 2 caractères Type de données : chaîne Valeurs acceptées : 03 = TRA* de l’émetteur 04 = Exception pour faible montant (inférieur à 30 euros) 05 = ART* du commerçant/de l’acheteur 06 = Liste blanche 07 = Entreprise 08 = Expédition retardée 09 = Authentification déléguée (portefeuille certifié) * Transaction risk analysis (Analyse du risque de transaction)

   
   Cependant, c’est toujours l’émetteur qui décide de la nécessité d’un processus d’authentification. Si l’émetteur insiste pour la mise en œuvre de 3DS, la transaction sera refusée avec le code d’erreur 40001139.
   Si la transaction est acceptée sans 3-D Secure, vous ne bénéficierez plus de la protection contre la responsabilité.
   
   
   Lorsque vos clients établissent un nouveau paiement récurrent auprès de vous, en vertu des règles PSD2, la première transaction doit toujours être authentifiée avec un processus d’authentification renforcée. Indiquez tous les paramètres 3DS et COF pertinents ainsi que leMpi.threeDSRequestorChallengeIndicator=04. Cela garantira que l’émetteur est au courant de cette demande et approuvera la transaction

Flux sans interaction / avec vérification

Si vous ne voulez pas demander une exemption et comptez sur le déploiement d’un flux sans interaction par l’émetteur tout en conservant votre protection contre la responsabilité, envoyez quelques paramètres supplémentaires.
L’envoi de ces paramètres pour ces marques augmente la probabilité d’un flux sans interaction :

• Carte Bancaire (si vous faites partie du programme des marchands à faible risque, ils sont fortement recommandés)
  ECOM_BILLTO_POSTAL_CITY
  ECOM_BILLTO_POSTAL_COUNTRYCODE
  ECOM_BILLTO_POSTAL_STREET_LINE1
  ECOM_BILLTO_POSTAL_POSTALCODE
  EMAIL
  OWNERTELNO
  Mpi.shippingIndicator
  REMOTE_ADDR
  
  
• MasterCard
  ECOM_BILLTO_POSTAL_CITY
  ECOM_BILLTO_POSTAL_COUNTRYCODE
  ECOM_BILLTO_POSTAL_STREET_LINE1
  ECOM_BILLTO_POSTAL_POSTALCODE
  EMAIL
  OWNERTELNO
  ADDMATCH
  REMOTE_ADDR
  
  

Vous pouvez même augmenter la probabilité d’un flux sans interaction et obtenir un taux de conversion plus élevé en envoyant plus de paramètres optionnels.

En revanche, il appartient toujours à l’émetteur de choisir de mettre en place un processus d’authentification. Dans le cas où l’émetteur insiste pour utiliser 3DS, la transaction sera refusée.

Soft Decline

Une séquence typique de transaction refusée par soft decline ressemble à ceci

1. Lors de votre première demande, vous envoyez FLAG3D=N et avec la valeur appropriée pour 3DS_EXEMPTION_INDICATOR aucun autre paramètre d’authentification. De cette façon, vous indiquez que vous souhaitez passer la procédure 3-D Secure. Il est possible que la transaction soit déjà acceptée à ce stade.
   Si elle est refusée par la banque de votre client parce qu’elle insiste pour réaliser la procédure 3-D Secure, nous l’indiquerons dans le paramètre de retour d’informations en envoyant NCERROR=40001139. La transaction sera placée en statut 2.
2. Pour récupérer cette transaction refusée, soumettez à nouveau la transaction en envoyant les paramètres suivants à notre plateforme
   1. La demande standard  Page de paiement hebergée / DirectLink telle qu’envoyée dans votre première demande en tant que nouvelle commande eCommerce ou DirectLink.
   2. FLAG3D=Y pour indiquer que la procédure 3-D Secure doit être effectuée
   3. Les paramètres d’authentification 3DSv2 comme décrit ici
   4. Mpi.threeDSRequestorChallengeIndicator=04 pour indiquer que la banque de votre client insiste pour réaliser la procédure 3-D Secure à la suite du Soft Decline.

Votre client devra réaliser avec succès la procédure d’authentification 3-D Secure au cours de la deuxième demande. Finalement, la transaction atteindra le statut 2 ou 9. Cela dépendra du fait que votre client ait réussi la procédure d’authentification et que le paiement soit accepté aussi bien par votre banque que celle de votre client

Soft Decline  est actuellement disponible pour les méthodes de paiement Visa, MasterCard, American Express et Carte Bancaire.

7.2 Test cards

You can use the following test card to simulate a 3-D Secure registered card in our test environment:

Frictionless Flow
Brand	Card number	Expiry date
VISA	4186455175836497	Any date in the future
Mastercard	5137009801943438	Any date in the future
American Express	375418081197346	Any date in the future
Carte Bancaire	4150557357382737	Any date in the future

Challenge Flow
Brand	Card number	Expiry date
VISA	4874970686672022	Any date in the future
Mastercard	5130257474533310	Any date in the future
American Express	379764422997381	Any date in the future
Carte Bancaire	4150550997933993	Any date in the future

More test cards numbers can be downloaded here.

7.3 Obtenir un aperçu des transactions 3-D Secure

Pour pouvoir faire un suivi de vos transactions et de leurs résultats 3-D Secure, nous vous proposons une façon d’accéder à vos rapports 3-D Secure depuis le Back Office.

Regardez cette vidéo qui explique comment paramétrer votre rapport rapidement et en toute simplicité.

8. Utiliser des possibilités supplémentaires

Notre Page de paiement hebergée offre beaucoup plus de fonctionnalités. Elles rendent cette solution encore plus adaptable à vos besoins spécifiques et vous offrent des possibilités supplémentaires pour faire prospérer votre entreprise.

Traiter des transactions via Alias Manager

Comme pour toutes nos solutions, vous pouvez utiliser notre Alias Manager pour créer, stocker et mettre à jour les données de votre carte sur la Page de paiement hebergée. Consultez notre chapitre dédié pour faciliter davantage le parcours de vos clients !

Recevoir et envoyer des e-mails pour les commandes

Notre système peut envoyer des e-mails de confirmation de commande à vous et à vos clients dès qu’un paiement a été finalisé. Pour utiliser cette option, allez dans Configuration > Technical Information > Transaction e-mails > E-mails to the merchant / E-mails to the customer. Sélectionnez les éléments suivants :

• E-mails to the merchant

E-mail address(es) for transaction-related e-mails	Votre ou vos adresses électroniques auxquelles les e-mails sont envoyés.
Receive transaction confirmation e-mails Yes, but only for e-Commerce transactions. Yes, for all transaction submission modes.	Recevez des e-mails pour les transactions que vous traitez via Page de paiement hebergée Toute autre de nos solutions
Receive e-mails in the event of offline transaction status changes Yes, but only at the time of the order authorisation request. Yes, for each offline status change (payment, cancellation, etc.).	Recevez des e-mails Pour les transactions avec le statut initial 5 ou 51/52 Pour les transactions avec l’un des premiers statuts suivants : 5 / 51 / 52 91 / 92 61 / 62 81 / 82 91 / 92

 

• E-mails to the customer

Support E-mail address to include in transaction-related e-mails	Indiquez votre adresse électronique dans l’e-mail
Support Phone number to include in transaction-related e-mails	Indiquez votre numéro de téléphone dans l’e-mail
I would like Worldline to send a transaction confirmation e-mail to the customer. I would like Worldline to send a transaction confirmation e-mail to the customer at the time of the capture. I would like Worldline to send a transaction confirmation e-mail to the customer at the time of the refund.	Vos clients reçoivent des e-mails pour les transactions qui bénéficient du statut 5 ou 9 après leur achat statut 9 après une demande de capture (statut 91) statut 8 après une demande de remboursement (statut 81)

Envoyer le lien de paiement par e-mail

Au lieu de rediriger vos clients vers notre page de paiement en temps réel, vous pouvez laisser vos clients choisir de saisir les données de leur carte de crédit quand ils le souhaitent !

Vous pouvez y parvenir en envoyant un e-mail à vos clients, qui contient la demande soit sous forme

• POST: un formulaire HTML avec des champs HTML cachés pour nous envoyer les paramètres requis
  Ce formulaire HTML fonctionne de la même manière que dans notre exemple de page de passage de commande de votre site de e-commerce
  
  
• GET: un lien constitué du point de destination, les paramètres nécessaires y étant ajoutés :
  https://ogone.test.v-psp.com/ncol/test/orderstandard.asp / orderstandard_utf8.asp?PSPID=TESTSTD&OrderID=order123&amount=12500¤cy=EUR&SHASIGN=8DDF4795640EB9FE9B367315C48E47338129A4F5& …

Dans les deux cas, vos clients aboutissent sur notre page de paiement sécurisée comme cela est décrit dans l’étape 2 de notre aperçu du flux de paiement et ils commencent le flux de paiement à ce moment-là.

Préselectionner les modes de paiement disponibles sur l’Page de paiement hebergée

Par défaut, notre plateforme affichera tous les modes de paiement sur la Page de paiement hebergée qui sont effectifs dans votre Back Office (Configuration > Payment methods). L’envoi d’un ou de plusieurs des paramètres suivants avec vos demandes de transaction définit la liste des modes de paiement disponibles sur l’écran de sélection des paiements.

Vous trouverez des informations détaillées (courte description, format, longueur maximale, etc.) pour chaque paramètre dans notre Parameter Cookbook.

Paramètre	Description / Valeurs possibles
PM	Payment method (ie. Visa) or payment method group (ie. credit cards) To display only one specific payment method on the Page de paiement hebergée, send this parameter together with the according value for BRAND: PM=CreditCard BRAND=VISA If the payment method belongs to a third-party payment method services (ie. Paypal, iDEAL etc.), we will redirect your customer directly to the respective homepage, omitting a redirection to our Page de paiement hebergée To display a payment method group (ie. credit cards), send only this parameter: PM=CreditCard Find a list of all accepted values.
BRAND	Specifies the payment method brand (ie. VISA) from the payment method group (ie. credit cards) as defined by PM Find a list of all accepted values.
PMLIST	Define a list of available payment methods on the Page de paiement hebergée. Combine multiple values of parameter PM (separate them by  a “;” (semicolon)): PMLIST=VISA;iDEAL Find a list of all accepted values for parameter PM.
EXCLPMLIST	Define a list of payment methods that should not be available on Page de paiement hebergée Combine multiple values of parameter PM (separate them by  a “;” (semicolon)) EXCLPMLIST= VISA;iDEAL Find a list of all accepted values for parameter PM.
CREDITDEBIT	Split payment methods Visa and MasterCard as separate credit and debit payment methods. This allows your customers to choose either of them by sending it along PM / BRAND: C: offer payment method as credit card D: offer payment method as debit card PM=CreditCard BRAND=VISA CREDITDEBIT=C

Utiliser la norme OGM-VCS pour l’ORDERID

Pour les modes de paiement KBC/CBC Online, ING Homepay et Belfius DirectNet, il est possible d’inclure une communication structurée (Gestructureerde mededeling) selon la norme OGM-VCS  dans vos rapports d’acquisition de paiement.

Cette communication structurée apparaît dans notre Back Office pour chaque transaction via Operations > View transactions ou est disponible en tant que paramètre STRUCT via notre outil de reporting électronique.

Pour utiliser cette fonctionnalité, vous devrez envoyer la valeur du paramètre ORDERIDcomprenant uniquement des chiffres.

En fonction de la longueur de l’ORDERID, le contenu suivant sera utilisé pour la communication structurée :

Longueur de l’ORDERID	Résultat
>12	PAYID + two check digits (as Modulo 97) will be used for structured communication
12 (including Modulo 97 checksum)	ORDERID will be used for structured communication. The same applies if this value is sent with parameter COM
11	PAYID + two check digits (as Modulo 97) will be used for structured communication
10 (not including Modulo 97 checksum)	ORDERID will be used for structured communication + two check digits (as Modulo 97) will be added by our system
Between 1 and 9	ORDERID + leading zeros + two check digits (as Modulo 97) will be used for structured communication. Depending on the length of the ORDERID, the amount of leading zeros will vary to get a length of 12 digits in total

Veuillez vous concerter avec votre acquéreur pour imprimer la communication structurée sur vos rapports de paiement, en tenant compte du fait que cela peut impliquer une modification de votre contrat d’acquisition.

Ce service n’est pas disponible pour ces modes de paiement s’il est proposé via Full Service. À la place, nous enverrons le PAYID en tant que communication structurée.

Afficher la Page de paiement hebergée dans l’iframe

Les iframes vous permettent d’intégrer la Page de paiement hebergée sur votre site Internet, tout en conservant votre propre URL dans le navigateur. Vos clients auront alors l’impression de rester dans votre environnement tout au long du processus de paiement.

Cependant, en raison de ses limites, nous ne recommandons pas d’utiliser cette fonctionnalité pour plusieurs raisons :

• Si votre URL fonctionne uniquement avec le protocole HTTP, l’icône du cadenas n’apparaîtra pas dans le navigateur de votre client. Vos clients pourraient alors douter de la sécurité de la page de paiement.
• Les services de modes de paiement tiers (Paypal, iDEAL, etc.) ne fonctionnent pas bien avec les iframes, occasionnant ainsi une mauvaise mise en page des résultats lors du processus de paiement.

Au lieu d’utiliser des iframes, nous proposons d’avoir recours aux possibilités définies afin d’adapter la présentation de la Page de paiement hebergée ou l’intégration via FlexCheckout.

Si vous souhaitez continuer à utiliser les iframes, assurez-vous :

• De les utiliser uniquement sur l’écran de sélection du mode de paiement.
• D’utiliser les fenêtres pour les modes de paiement externes, dans la mesure du possible, afin de garantir la visibilité des applications web tierces.

Obtenir des données supplémentaires dans le retour d’information sur les transactions

En plus des paramètres de retour d’information que vous pouvez choisir dans le Back Office, vous pouvez définir vos propres paramètres qui doivent être inclus dans le retour d’information. Il s’agit de paramètres d’intercommunication que vous envoyez dans la demande de transaction et qui sont envoyés à l’identique dans le retour d’information. Pour utiliser cette fonctionnalité, ayez recours aux paramètres suivants :

Paramètre	Description / Valeurs possibles
COMPLUS	Pass a value within this parameter you would like to receive in the feedback Sending COMPLUS=1234 would be sent in the feedback like this: https://www.yourwebsite.com/acceptpage.asp?[…standard.parameters…]&COMPLUS=1234 […standard.parameters…]
PARAMPLUS	Pass both parameter names and values you would like to receive in the feedback Sending PARAMPLUS=SessionID=126548354&ShopperID=73541312 would be sent in the feedback like this: https://www.yourwebsite.com/acceptpage.asp?[…standard.parameters…]& SessionID=126548354&ShopperID=73541312

Utiliser les URL variables de retour d’information sur les transactions

Si vous disposez de plusieurs boutiques, vous pouvez adapter l’URL de retour d’information dans le Back Office pour chacune des transactions.

Pour ce faire, veuillez procéder comme suit :

• Dans le Back Office, allez dans Configuration > Technical Information > Transaction feedback > eCommerce > Direct HTTP server-to-server request. Ajoutez le caractère générique « <Paramvar> » pour la partie de l’URL que vous souhaitez modifier au niveau de la transaction.

Example:
https://www.yourwebsite.com/<PARAMVAR>/yourpage.asp

• Dans votre demande de transaction, envoyez pour le paramètre PARAMVAR la valeur qui remplira le caractère générique « <Paramvar> ».
  
  Example:
  Pour PARAMVAR=boutique1, le retour d’information pour cette transaction serait envoyé sur
  https://www.yourwebsite.com/shop1/yourpage.asp

Définir le code opération par transaction

Par défaut, notre plateforme traite chaque demande de transaction comme une autorisation (statut 5) ou des ventes directes (statut 9). Vous pouvez écraser ce Default operation code pour chacune des transactions avec le paramètre supplémentaire OPÉRATION. Cela vous permet de décider au cas par cas si vous voulez demander une autorisation ou une vente directe :

Paramètre	Description / Valeurs possibles
OPERATION	Send for each transaction to override the Back Office configuration Accepted values: RES = authorisation (status 5) SAL= direct sale (status 9)

Associer les transactions à l’utilisateur

Si plusieurs de vos collaborateurs travaillent avec votre Back Office et votre boutique en ligne, vous pouvez enregistrer les transactions associées à un utilisateur spécifique (à savoir les agents du centre d’appel qui créent les transactions via la fonction de lien de paiement). Pour ce faire, vous devez envoyer le paramètre supplémentaire :

Paramètre	Description / Valeurs possibles
USERID	The name of the user as defined in your Back Office (Configuration > Users) In the transaction overview (Operations > View transactions / Financial History), the creator of the transaction is named by the formula “UserID/PSPID/User type”. If the USERID does not exist, we will replace it by the default USERID of the account (your PSPID)