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 :

[toc ordered_list= »false »]

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…