FAQ - Installation et paramétrage

Vous êtes en phase d'installation, vous avez besoin de conseils ou d'assistance ? Vous retrouvez une liste des questions fréquemment posées à notre équipe technique.

Comment tester la solution de paiement avant d'être opérationnel ?

C'est très simple, notre serveur de test est disponible avant et pendant la phase opérationnelle. Une configuration de test temporaire sans engagement est disponible auprès de nos responsables flux hors de tout engagement contractuel.

Où peut-on trouver des numéros de carte pour effectuer des tests ?

Sur la page de paiement, vous trouverez une icône clignotante "test". En cliquant sur cette icône, une fenêtre s'affiche et fournit différents numéros de cartes de test. Sélectionnez l'une des cartes pour simuler le paiement.

Vous disposez de plusieurs cartes de test :

  • une carte 16 pan (carte française) acceptant le paiement
  • une carte 16 pan refusant le paiement
  • deux cartes 15 pan (cartes étrangères) sur le même principe.

À quoi correspondent les différentes URL_RETOUR du paramétrage ?

Ce sont des URL du site commerçant appelées par notre site de transaction en fonction des événements suivants :

  • url_retour : correspond au lien affiché en bas de notre page de paiement, avant que le client ne valide sa saisie. Ce lien permet à l'acheteur de revenir sur une page de votre boutique sans avoir effectué de paiement.
  • url_retour_ok : correspond au lien (permettant à l'acheteur de retourner sur une page de votre boutique) affiché en bas de notre page de paiement une fois le paiement effectué et accepté.
  • url_retour_err : correspond au lien (permettant à l'acheteur de retourner sur une page de votre boutique) affiché en bas de notre page de paiement une fois le paiement effectué et refusé.

À quoi sert l'URL de confirmation CGI2 ?

Cette URL du site commerçant est automatiquement appelée (sans action du client) après les contrôles de la carte du client auprès de sa banque. Elle permet de retourner au site commerçant le résultat de la demande de paiement.

Que faire lorsque je rencontre une erreur "CGI2 not OK" ?

Vous devez tout d'abord effectuer les vérifications de base suivantes :

  • L'adresse de "Retour" au site commerçant a-t-elle été fournie à notre équipe technique ?
  • Cette adresse est-elle accessible depuis l'extérieur ?
  • L'adresse de retour est-elle accessible sur le port 80 (http) ou 443 (https) ?
  • Le traitement de l'appel entre votre serveur et notre serveur est-il supérieur à 30 secondes ?
  • N'avez-vous pas fait une redirection à la réception du code retour paiement ?

J'ai le message "Ce TPE est fermé".

Depuis le site de test, les TPE non utilisés pendant 15 jours glissants sont fermés automatiquement. Vous pouvez le rouvrir depuis le tableau de bord.

J'ai le message "Les informations transmises par votre commerçant ont une signature non valide..."

Depuis le site de test, les TPE non utilisés pendant 15 jours glissants sont fermés automatiquement. Vous pouvez le rouvrir depuis le tableau de bord.

J'ai le message "Les informations transmises par votre commerçant ont une signature non valide..."

Causes possibles

  • Le formulaire que vous nous avez envoyé ne contient pas toutes les informations requises.
  • Le calcul du sceau MAC est erroné.
  • Le calcul du sceau MAC est effectué avec une mauvaise clé.

Résolution du problème

Suivez scrupuleusement le cheminement décrit ci-dessous ; à la fin de chaque étape pour laquelle vous avez effectué des changements dans votre implémentation, effectuez de nouveaux tests de paiement. S'ils ne sont pas fructueux, passez à l'étape suivante.
Attention, ne sautez pas d'étape !

Étape 1

Vérifiez que toutes les variables envoyées dans le formulaire :

  • sont présentes
  • sont correctement orthographiées
  • respectent la casse
  • respectent les éventuelles restrictions sur le format
  • respectent les caractères autorisés.

Ces variables se nomment : "TPE", "date", "montant", "reference", "texte-libre", "version", "lgue", "societe", "mail". Auxquelles s'ajoutent, si votre TPE est en paiement fractionné : "nbrech", "dateech1", "montantech1", "dateech2", "montantech2", "dateech3", "montantech3", "dateech4", "montantech4".

Étape 2

Vérifiez que vous avez réussi à éviter les erreurs inhérentes à certains champs particuliers :

  • la valeur de la version MAC est-elle à une chaîne de 40 caractères hexadécimaux (valeurs autorisées : de 0 à 9 et entre A et F) ?
  • la valeur de la variable version correspond-elle à 3.0 ?
  • la valeur de la variable date est-elle bien au format JJ/MM/AAAA:HH:MM:SS ?
  • la valeur de la variable référence est-elle bien une chaîne ne contenant que des lettres (non accentuées) et des chiffres pour une longueur maximale de 12 caractères ?
  • la variable texte-libre est-elle correctement orthographiée, en respectant la casse et avec le caractère tiret ("-") et non le caractère ("_") ?

Étape 3

Vérifiez que la chaîne sur laquelle vous calculez le sceau MAC respecte le formalisme décrit précédemment, à savoir :
<TPE>*<date>*<montant>*<reference>*<texte-libre>*<version>*<lgue>*<societe> *<mail>*<nbrech>*<dateech1>*<montantech1>*<dateech2>*<montantech2>*<dateech3>*<montantech3>*<dateech4>*<montantech4>*

Soyez particulièrement attentif au fait que les données utilisées doivent être les mêmes que celles que vous fournissez dans le formulaire de paiement; le meilleur moyen pour atteindre cet objectif est de stocker à l'avance les différentes informations, puis d'utiliser ce stockage pour le calcul du sceau MAC et pour la construction du formulaire. Au contraire, renseigner les données à la volée peut induire des différences entre celles utilisées pour le calcul du sceau et celles utilisées pour la construction du formulaire (par exemple, pour le champ date, il peut y avoir une différence de quelques secondes).

Étape 4

Vérifiez que vous utilisez la bonne clé :

  • utilisez la dernière clé fournie par notre service technique. En cas de doute, faites une vérification.
  • vérifiez que la clé correspond à votre algorithme de calcul de sceau (SHA1 ou MD5)
  • Contactez notre service de support et demandez de valider avec vous que vous utilisez bien la bonne clé.

Si malgré toutes ces vérifications vous obtenez toujours ce message d'erreur, le problème réside dans l'intégration de notre solution dans votre système d'information.
La grande diversité des langages et des spécificités liées à l'environnement utilisés pour l'implémentation de notre solution de paiement, sont autant de paramètres dont nous ne maîtrisons pas tous les aspects et par conséquent, ils ne nous permettent pas de vous fournir un support personnalisé plus ample.

J'ai le message "Le site de votre commerçant n'a pas été identifié par notre serveur."

Causes possibles :

  • le numéro de TPE est incorrect ou inexistant ;
  • le code société est incorrect ou inexistant ;
  • le code langue est incorrect ou inexistant.

Vérifiez que les variables "TPE", "societe" et "lgue" sont présentes dans le formulaire et correctement orthographiées. Certains caractères ne sont pas autorisés (voir documentation technique).

Pourquoi mon "URL de confirmation CGI2" reçoit-elle des codes retour différents pour une même référence ?

Vos clients ont droit à 3 essais pour saisir leurs informations bancaires pour une même référence dans un délai maximum de 45 minutes. Après chaque tentative, nous envoyons son résultat sur votre URL de confirmation. Vous pouvez donc recevoir plusieurs notifications de refus (code retour "Annulation") avant de recevoir une éventuelle notification de paiement (code retour "paiement") pour une même référence.

Exemple d'une cinématique avec plusieurs appels de l'URL de confirmation :

Un client souhaite payer la référence ref0001 mais n'obtient pas d'autorisation de paiement avec la carte bancaire qu'il utilise.
Notre serveur va envoyer une notification de refus :
TPE=1234567&date=05%2f12%2f2006%5fa%5f11%3a55%3a23&montant=62%2e75EUR&reference=ref0001
&MAC=e4359a2c18d86cf2e4b0e646016c202e89947b04
&texte-libre=LeTexteLibre
&code-retour=Annulation&cvx=oui
&vld=1208&brand=VI
&status3ds=1
&motifrefus=Refus&originecb=FRA&bincb=010101
&hpancb=74E94B03C22D786E0F2C2CADBFC1C00B004B7C45&ipclient=127%2e0%2e0%2e1&originetr=FRA&veres=Y&pares=Y

Le client à la possibilité de refaire une tentative de paiement et il utilise sa seconde carte bancaire pour payer la référence ref0001. Le paiement est cette fois-ci accepté.
Notre serveur va envoyer une notification de paiement :
TPE=1234567&date=05%2f12%2f2006%5fa%5f12%3a15%3a33&montant=62%2e75EUR&reference=ref0001
&MAC=f4562a2c18d86cfdbaf646016c202e89945841
&texte-libre=LeTexteLibre
&code-retour=paiement&cvx=oui
&vld=1210&brand=VI
&status3ds=1
&numauto=010101&originecb=FRA&bincb=010101
&hpancb=12754C03C22D786E0F2C2CADBFC1C00A25df6322&ipclient=127%2e0%2e0%2e1&originetr=FRA&veres=Y&pares=Y

Comment modifier l'échéancier par défaut de mes paiements fractionnés ?

Lorsque votre TPE est en paiement fractionné, il est configuré pour respecter un échéancier par défaut que vous avez défini lors de la souscription de votre contrat.

Vous avez la possibilité de définir un échéancier propre à chaque commande afin de passer outre l'échéancier par défaut de votre TPE. Cet échéancier doit respecter les contraintes suivantes :

  • un nombre d'échéances compris entre 2 et 4 (paramètre nbrech)
  • la somme des échéances est égale au montant de la commande (paramètres montantech1, montantech2, montantech3, montantech4)
  • les dates d'échéances sont séparées d'une durée d'un mois (paramètres dateech1, dateech2, dateech3, dateech4)

Comment calculer la date de mes échéances ?

Les dates d'échéances doivent être séparés d'une durée d'un mois.
La durée d'un mois ne correspond pas à un nombre de jours précis mais à la durée entre deux mêmes jours d'un mois calendaire ou à défaut au jour le plus proche possible.

Exemples :

  • Si la 1ère échéance a pour date le 01/01/2010, la 2ème échéance aura pour date le 01/02/2010, la 3ème le 01/03/2010 et la 4ème le 01/04/2010.
  • Si la 1ère échéance a pour date le 31/01/2010, la 2ème échéance aura pour date le 28/02/2010, la 3ème le 31/03/2010 et la 4ème le 30/04/2010.
  • Si la 1ère échéance a pour date le 30/01/2012, la 2ème échéance aura pour date le 29/02/2012, la 3ème le 30/03/2012 et la 4ème le 30/04/2012.

Si vous ne respectez pas ce système de calcul pour les dates des échéances, vous obtiendrez le message d'erreur "les données du formulaire sont incorrectes".