Les 12 tests auxquels toute intégration de paiement doit être soumise

Les problèmes de paiement sont souvent rares, mais leurs répercussions peuvent être importantes. Un client peut effectuer un double paiement, une commande peut rester en attente à tort ou un remboursement peut n'apparaître que dans un seul système. Grâce à un ensemble de tests fixes, vous rendez ces exceptions prévisibles.

Statuts des transactions

• Paiement effectué avec succès, avec le montant et la référence corrects
• Paiement refusé, la vente restant en cours
• Le client annule sans que le statut de paiement soit erroné
• Délai d'attente à l'issue duquel le statut définitif est récupéré

Un flux fiable commence par un connexion sécurisée entre votre caisse et votre terminal de paiement ou votre API de paiement.

Messages en double et retardés

• Double clic ou demande répétée sans double transaction
• Le webhook est reçu deux fois sans effet double
• Le webhook arrive en retard ou dans un ordre différent
• La page de retour est affichée sans que le statut du fournisseur ait été confirmé

Tu veux d'abord comprendre Comment fonctionne une connexion à une caisse enregistreuse ?? Consultez également les explications techniques.

Remboursement et rectification

• Remboursement intégral avec mise à jour du statut de la caisse ou de la commande
• Remboursement partiel, avec indication du montant pris en charge et du montant correct
• Remboursement refusé ou suspendu, avec un suivi clair

Dans le cadre des ventes en ligne, les remboursements et les corrections jouent également un rôle important ; consultez donc nos informations sur paiements en ligne.

Récupération et sécurité

12. Redémarrez la caisse, le terminal, le routeur ou le service d'intégration pendant une transaction et vérifiez que le système a bien redémarré. Testez également les identifiants expirés, les droits insuffisants et la séparation entre l'environnement sandbox et l'environnement de production.

Les journaux doivent fournir suffisamment de contexte sans contenir de données cartographiques ni d'informations confidentielles.

Test avec des références uniques

Utilisez des identifiants uniques pour chaque commande et chaque tentative de paiement. Définissez quel statut fait autorité et comment un opérateur peut retrouver une transaction. Cela évite qu'un test ne soit évalué uniquement sur la base de captures d'écran.

Conservez les justificatifs concernant le scénario, le résultat attendu, le résultat réel, la version du logiciel et la date.

Refaites des tests après les mises à jour

Répétez les scénarios critiques après chaque mise à jour majeure du système de caisse, des plugins, du firmware des terminaux ou des API. Automatisez ces tests dans la mesure du possible, mais conservez un test de bout en bout utilisant du matériel de test réel et l'environnement du fournisseur.

Désignez un responsable chargé de valider la nouvelle version.

Le bon choix commence par votre fonctionnement

Une intégration de paiement est prête à être mise en production lorsque l'équipe sait ce qui se passe en cas de réussite et en cas d'incertitude. Un test de régression systématique vous protège contre les problèmes susceptibles de réapparaître après des mises à jour.