Modules de paiement : ce qu’il faut vérifier

Modules de paiement : ce qu’il faut vérifier

Tout site de vente en ligne dispose d’un ou plusieurs modules de paiement, sauf cas exceptionnel ou de vente indirecte.

Le choix de la solution en elle-même dépend beaucoup des besoins du marchand en termes de service(s) ainsi que des frais bancaires associés qui auront été probablement négociés.

Ayant moi-même travaillé pour un fournisseur de paiement FIA-NET avec l’ex-solution ReceiveAndPay devenue Kwixo, je peux témoigner d’une certaine expérience dans le développement du connecteur de paiement.

Le connecteur c’est ce qui va faire le lien entre le site marchand et la solution de paiement et entre la solution de paiement et le site marchand.

Si vous travaillez avec une plateforme comme Magento ou PrestaShop, il y a de fortes probabilités que vous embarquiez un connecteur pré-développé pour ces plateformes.

Or je constate que souvent le développement a été réalisé par des personnes n’ayant  aucune vision globale de ce qu’est un connecteur et de ce qu’il doit faire ou éviter. Cela aboutit souvent à des situations où ces modules deviennent inutilisables et même préjudiciables aux sites qui l’utilisent.

Je vais donc vous énumérer une liste de points sensibles à vérifier impérativement :

1. S’assurer que les informations envoyées soient les bonnes

Tout particulièrement le montant à payer. Ne testez pas seulement les cas simples, mais surtout les cas particuliers qui peuvent toucher au montant à payer surtout quand le reste à payer est partiel : code promo, utilisation de points fidélités, de bons d’achats, de frais de port gratuits…

Si vous travaillez avec l’étranger, assurez-vous aussi que les montants avec/sans TVA soient bons et surtout que la somme à payer est envoyée dans la devise voulue.

2. S’assurer de l’intégrité des données envoyées du site à la solution de paiement

Certaines solutions de paiement y sont très vulnérables car la solution de paiement ne vérifie pas que les données sont arrivées non-modifiées, d’autres comme ReceiveAndPay n’y sont pas sensibles. Dès lors, rajouter une vérification aura un intérêt rejoignant le point n°1.

Pour les autres en revanche la vérification lors de la validation bancaire de la transaction est indispensable. Certains ont sûrement en mémoire l’épisode du module de paiement Paypal pour Magento qui ne vérifiait rien et qui a occasionné des fraudes au paiement.

3. Bannir l’annulation automatique des commandes

La plupart des connecteurs de paiement annulent automatiquement les commandes si le paiement est en échec, si je n’ai rien contre une règle d’annulation volontaire je m’insurge contre les modules qui imposent l’annulation comme seule action lors d’un échec de paiement. J’ai baptisé ce phénomène « la dictature des modules de paiement ».

Un bon module vous laissera choisir entre annuler les commandes ou en faire autre chose selon la plateforme e-commerce utilisée.

Il faut savoir qu’un échec de paiement n’est pas forcément un problème financier et que tous les témoignages que j’ai eu jusqu’à présent me parlent d’un taux de conversion entre 15 et 20% sur rappel téléphonique suite à un échec de paiement.

Si la commande est perdue (car elle a été annulée), il est évident que le processus de conversion va être plus difficile.

4. Ne jamais valider les commandes au retour de l’internaute sur le site marchand

En effet, au retour de l’internaute sur le site se trouve systématiquement une information sur l’état du paiement, il est important de savoir que cette information n’a pas pour but de valider la commande mais d’aider le site à savoir quoi faire de l’internaute dont il a perdu la trace (en gros : page de remerciement ou retour panier ?).

De plus sur certaines solutions de paiements, l’information donnée au retour internaute est incomplète et pour cause ce n’est pas le retour bancaire !

Enfin 20% des internautes ne reviennent jamais sur un site après avoir payé, cela signifie donc 20% de commandes dont l’information de paiement est perdue.

La validation du paiement doit donc se faire exclusivement au retour bancaire.

5. S’assurer de l’origine et de l’intégrité des données d’un retour bancaire

Le retour bancaire se fait toujours de serveur à serveur, l’internaute n’y est jamais impliqué.

Toutefois la page de retour bancaire est souvent publique afin qu’elle puisse être appelée librement par le serveur de la banque, il convient donc de s’assurer que les vérifications sur l’origine de l’appel (est-ce bien la banque qui m’envoie ces données ?) et l’intégrité des données (les données que je reçois sont-elles authentiques ?) soient mises en places.

Toutes les solutions de paiement ont une procédure pour cela (encore faut-il qu’elle soit en place).

6. La double vérification c’est le mal

Certains petits malins pensent toujours que plus c’est compliqué plus c’est intelligent, or de mon expérience plus on fait simple moins il y a de risques.

On trouvera donc mis en place la validation de la commande au retour internaute (cf point 4) doublée de la validation au retour bancaire  (cf point 5) et là c’est le ponpon, non seulement ça ne sert à rien (si vous êtes arrivé jusque là vous devriez avoir compris pourquoi) mais en plus cela provoque souvent beaucoup de bugs :

  • invalidation des commandes,
  • incohérences des informations sur l’état du paiement,
  • problèmes de datation des évènements,
  • double validation des commandes (avec envoi en double des e-mails).

En bref : à bannir.

7. Bien gérer les transactions abandonnées

Un abandon de transaction se produit lorsque l’internaute a été redirigé vers la solution de paiement par le connecteur de paiement et qu’il s’en va. Contrairement aux échecs de paiement, aucune tentative de paiement n’a eu lieu.

Internet étant ce qu’il est, il est impossible pour le serveur de détecter la fermeture du navigateur et donc de savoir si l’internaute est parti.

Certaines solutions gèrent ce cas avec un retour bancaire dédié tandis que d’autres ne font rien. Dans le second cas, c’est donc au connecteur de paiement de gérer l’abandon de la transaction.

C’est assez simple à faire : on détermine un délai d’attente, au bout duquel on effectue une action soit :

  • pour annulation,
  • pour blocage
  • pour interrogation de la solution de paiement.

Sans en avoir l’air, les abandons de transaction représentent une part importante des internautes (10 à 20% des transactions sont abandonnées), il est donc important de veiller à avoir un retour correct sur ces cas.

8. “La solution de paiement ne fonctionne pas !” me dit mon client

On termine sur une anecdote un peu hors sujet que j’ai vécue : un e-Commerçant m’avait remonté que beaucoup de paiements étaient perdus et qu’après les avoir contacté, ses clients lui assuraient avoir été incapables de payer en raison d’un problème technique.

Ce marchand me demande alors de régler le problème pour que ses clients puissent payer et finaliser leur commande.

Cherchant à comprendre ce qui s’est passé, j’ai pris mon téléphone et contacté les clients par moi-même afin d’en savoir plus sur ce problème technique. Et là grosse surprise, après leur avoir expliqué que j’intervenais en tant que représentant de la solution de paiement dans le simple but d’identifier le problème, tous les clients m’expliquent qu’ils n’ont tout simplement pas voulu procéder au paiement.

L’argument du problème technique n’a été qu’une fausse excuse pour le client lui évitant de dire en face de l’e-Commerçant qu’il n’était finalement plus intéressé par son achat. Il convient donc de reproduire les bugs supposés dans des tests en conditions identiques…

2 pings pour “Modules de paiement : ce qu’il faut vérifier

7 commentaires pour “Modules de paiement : ce qu’il faut vérifier

  1. Merci pour cet article. J’aurais tendance à penser qu’il manque l’aspect fraude dans votre analyse. Les banques nous tournent souvent le dos face à ces dernières et poussent donc les développeurs les plus avertis à mettre les mains là où il ne faudrait pas. Je fais surtout référence à ATOS dans ma remarque.

    • Merci pour votre avis ! En effet, la fraude est un sujet important…
      … mais cet article se concentre plus sur les problèmes des connecteurs de paiement que sur les solutions de paiement elles-mêmes.

      La fraude étant un sujet à part entière, elle fera probablement l’objet d’un article dédié dans le futur :-)

  2. Merci beaucoup pour votre article que j’ai lu avec attention, surtout la partie “Bien gérer les transactions abandonnées”, car c’est un problème auquel je n’ai pas encore trouvé de solution.
    Je travaille pour un site d’e-commerce et le processus de validation de commande enregistre chaque nouvelle commande en base AVANT le paiement. Ce qui fait que si le client abandonne sa commande en cours de paiement et qu’il recommence un peu plus tard, un nouveau numéro de commande est créé et cela gène beaucoup la comptabilité. Je vais de ce pas creuser un peu pour voir ce que le connecteur de paiement du site propose :)

    • Pour le numéro de commande c’est tout à fait normal, c’est d’ailleurs typiquement le comportement natif de Magento, que ça gène la compatibilité n’est pas un souc (qu’elle se débrouille) surtout que les commandes ne sont jamais enregistrées en compta ce sont les factures qui le sont.

      Pourquoi je dis ça :
      Le fait que la commande existe même s’il n’y a pas paiement est un formidable levier de CA, en effet l’ensemble des ecommerçants avance un chiffre de 20% de taux de conversion sur les paiements abandonnés, autrement dit si on téléphone suite à abandon de paiement on en récupère 20%.

      Bien gérer les transactions abandonnées c’est surtout s’assurer s’il n’y a pas paiement que le statut de la commande soit bien mis à jour, pour différencier les commandes payées des commandes abandonnées.

      • Merci beaucoup, Fabrice, pour votre réponse très rapide. En effet, depuis quelques mois, notre site utilise Ogone qui est apparenté à Magento. Avant on utilisait Bluepaid qui ne demandait pas de numéro de commande et on pouvait donc enregistrer la commande (et donc créer un numéro) après le paiement et seulement si il est bien passé. Ce qui n’est pas le cas d’Ogone.

        Par ailleurs, nous avons établi que la plupart d’abandons de transactions se faisaient parce que le client a finalement décidé de payer par chèque. Du coup, on se retrouve avec deux commandes (ou des numéros de factures si vous préférez) qui se suivent de près et dont la première est inachevée. Elle est, bien sûr, annulée par la suite, mais on se fait gronder par la compta (ils y sont très intransigeant pour les numéros de facture :) )

        Ce que je cherche en ce moment, c’est un algorithme approximatif du processus d’enregistrement de commandes et de gestion d’abandon de transaction, car, si le client abandonne son panier, c’est une chose et il y a des solutions pour bien gérer ces cas-là, mais comme vous le dites dans votre article, on ne peut pas détecter si le client ferme son navigateur pendant qu’il est sur la page du site de paiement et si on a déjà enregistré un numéro en base, il est perdu.

        • Je pense que vous avez un double problème, tout d’abord, dans Magento les commandes ne sont pas des factures, la numérotation des factures et des commandes est volontairement séparée (et pour cause !), les commandes ne sont donc jamais à transmettre à la comptabilité, seule les factures générées doivent l’être. Vous faites donc une confusion qui conduit évidemment à ce que la compta se plaigne et pour le coup c’est normal puisque vous ne leur envoyez pas les bons documents.

          Pour l’abandon de transaction si la solution de paiement ne le fait pas (Ogone dans votre cas) c’est au module de paiement de se substituer à lui (le module Ogone pour Magento), s’il ne le fait pas alors c’est à développer.

          Sur le principe ce n’est pas très difficile :
          On accorde un délai (arbritraire) pour qu’une commande reçoive le retour bancaire, mettons 1h, si passé ce délai rien n’a été reçu, on bloque la commande, attention ne les annulez pas, en les bloquant (c’est un statut de commande natif Magento) vous pouvez ainsi contacter l’internaute et lui proposer une alternative (chèque par exemple), si l’abandon est effectif alors vous pouvez annuler la commande, sinon émettez la facture et le BL et la commande sera validée manuellement.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *