1. Introduction

Si vous êtes un nouveau marchand, veuillez envisager l’utilisation de notre nouvelle interface pour ce mode d’intégration.

Consultez ses fonctionnalités et possibilités dans notre guide dédié.

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!

hpp-shortCe 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

HPP-longLe 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).
  1. Votre client saisit les informations relatives à sa carte de crédit sur notre Page de paiement hebergée sécurisée.
  1. Nous redirigeons le client vers sa banque émettrice à des fins d’authentification 3-D Secure.
  2. Le titulaire de carte s’identifie. Notre système reçoit le résultat de la part de l’émetteur.
  3. 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.
  1. 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.
  2. 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

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).

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 :

    https://shared.ecom-psp.com//v2/images/guides/e-commerce/e-com-adv_css_01.jpg?language_id=1

    .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.

    https://shared.ecom-psp.com/v2/images/guides/e-commerce/Group 18.svg?language_id=1

    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 :

    https://shared.ecom-psp.com/v2/images/guides/e-commerce/Group 18.svg?language_id=1

    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 :

    https://shared.ecom-psp.com/v2/images/guides/e-commerce/Group 18.svg?language_id=1

    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. 

    https://shared.ecom-psp.com//v2/images/guides/e-commerce/e-com-adv_css_01.jpg?language_id=1

    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 Ingenico 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.
    1. 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.

    2. 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

    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 Ingenico 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.

    Notez que tous les émetteurs ne communiquent pas les raisons pour lesquelles ils refusent des transactions. Par conséquent, dans certains cas, CH_AUTHENTICATION_INFO est vide.

    Utilisez les numéros de carte suivants dans notre Environnement de test pour simuler la réponse d’un émetteur :
    Amex: 349586710563469
    MasterCard: 5111823134937549
    Visa: 4010759044222272

    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

      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

      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 Ingenico to send a transaction confirmation e-mail to the customer.
      • I would like Ingenico to send a transaction confirmation e-mail to the customer at the time of the capture.
      • I would like Ingenico 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

      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à.

      • Si vous choisissez d’implémenter cette fonctionnalité via un appel en GET, faites bien attention à ce qu’aucune donnée personnelle de votre client, comme un email ou un numéro de téléphone, ne soit transmise au sein de la requête
      • Intégrez le paramètre SHASIGN dans le formulaire/lien HTML comme vous le faites pour toute autre demande de paiement
      • Laissez le champ "URL de la page du marchand contenant le formulaire de paiement qui appellera la page: orderstandard.asp" (Configuration > Information technique > Contrôle de données et d'origine > Contrôles pour e-Commerce & Alias Gateway) vide dans votre PSPID vers lequel la demande est envoyée (paramètre PSPID). Dans le cas contraire, notre plateforme refuse la demande avec un message d’erreur "unknown order/1/r/” error message

      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:

      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)

      Questions fréquemment posées

      Dans le menu de votre compte Worldline, vous pouvez facilement rechercher vos transactions en cliquant sur « Opérations », puis sur « Afficher les transactions » ou « Historique financier », selon le type de résultat que vous recherchez.

      Cliquez sur Consulter vos transactions pour obtenir plus d’informations.

      Par défaut, vous pouvez envoyer des marchandises ou fournir un service lorsque la transaction a atteint le statut « 9 - Paiement demandé ». Même si le statut 5 est un statut positif, il s’agit d’une simple réserve d’argent temporaire sur la carte du client. Une transaction possédant le statut 5 doit être confirmée (manuellement ou automatiquement), pour passer au statut 9, qui est le dernier statut positif pour la plupart des méthodes de paiement.

      Cliquez sur Statuts des transactions pour obtenir plus d’informations.

      Vous pouvez facilement rembourser un paiement en cliquant sur le bouton « Rembourser » dans l’aperçu des commandes d’une transaction (dans « Afficher les transactions »). Si votre compte le permet, vous pouvez également effectuer des remboursements avec une demande DirectLink ou l’option de téléchargement de fichier Batch (en cas de transactions multiples).

      Sachez que l’option « Remboursement » doit être activée sur votre compte.

      Cliquez sur Gérer vos transactions pour obtenir plus d’informations.

       

      Si vous souhaitez vérifier les détails d’une commande/transaction ou gérer certaines transactions, vous devez utiliser l’option « Gestion des transactions ». « Historique financier » est l’option la plus pratique pour consulter périodiquement les fonds entrants et sortants.

      Pour plus d’informations, consultez Gestion des transactions vs Historique financier.

      Vous ne pouvez effectuer des remboursements que sur les transactions qui ont obtenu u statut 9 sur les dernières 24 heures. L’annulation ou la suppression d’un paiement est possible dans un délai de 24 heures après que le statut final de la transaction soit reçu (Statut 9 ou 5).

      Pour connaître l’heure limite de votre acquéreur, nous vous recommandons de contacter directement notre service clientèle.

      Le message « Une erreur s’est produite. Veuillez réessayer ultérieurement. Si vous êtes le propriétaire ou l’intégrateur de ce site Web, veuillez vous connecter au Back Office Worldline pour en savoir plus sur cette erreur. » est un message d’erreur générique qui est renvoyé si un problème technique spécifique survient au moment de l’appel de la page de paiement. Nous n’affichons pas la véritable erreur sur la page de paiement, principalement pour des raisons de sécurité, mais aussi pour éviter de susciter la confusion parmi vos clients.

      Dans votre compte Worldline, vous pouvez facilement trouver les erreurs qui se sont produites lorsque le message d’erreur générique s’affiche en accédant à « Configuration » > « Rapports d’erreurs ». La véritable signification de ces erreurs est décrite sur la page Erreurs possibles.