Gestion des erreurs et conformité
Gestion des erreurs et conformité
Sous-page — Paiement
Catalogue des erreurs possibles (refus, timeouts, données invalides), stratégies de reprise et messages utilisateur. Règles PCI et recommandations pour ne jamais stocker de données sensibles côté serveur.
Points couverts
Dépendance fournisseur externe
L’autorisation et le paiement passent par un prestataire externe et peuvent échouer pour diverses raisons (refus bancaire, solde insuffisant, anti-fraude).
Validation des champs carte
Format attendu : numéro, MM/AA, CVV — validation en entrée, masquage et retour clair à l’utilisateur.
Conformité PCI
Ne pas stocker de données sensibles sans conformité ; conserver uniquement des métadonnées non sensibles (référence, code autorisation, dernier 4).
Retour transactionnel
Recevoir le retour transactionnel, déterminer le statut et enregistrer la référence dans l’inquiry ou le contrat.
Stratégies de reprise
Plans de retry, backoff, gestion des timeouts et règles pour éviter les doublons.
Expérience utilisateur
Microcopies sécurisées et actions recommandées pour guider l’utilisateur après une erreur.
Workflow 1 — Validation des champs de paiement (avant soumission)
Étape 1 — Masquage et ergonomie
Présentez le champ numéro de carte masqué (affichez uniquement les 4 derniers chiffres après saisie). Affichez un clavier numérique sur mobile et formatez l’entrée en groupes lisibles (ex. 4-4-4-4).
Étape 2 — Vérifications de format
Vérifiez : longueur plausible du numéro, mois (01–12), année (YY ou YYYY) qui n’est pas antérieure au mois courant, et CVV (3 ou 4 chiffres selon la carte). Rejetez les formats manifestement invalides avant appel au prestataire.
Étape 3 — Contrôle de validité (Luhn et logique)
Appliquez une vérification de Luhn sur le numéro pour détecter les erreurs de frappe. Vérifiez que la date d’expiration n’est pas passée et que le CVV contient uniquement des chiffres.
Étape 4 — Feedback immédiat
Affichez des messages clairs en ligne pour chaque champ (ex. « Numéro invalide », « Date expirée », « CVV incomplet »). N’utilisez pas de jargon bancaire technique.
Étape 5 — Accessibilité et découplage visuel
Assurez une couleur/bordure + texte explicatif (non seulement couleur) pour les erreurs, pour que les utilisateurs daltoniens ou utilisant lecteurs d’écran reçoivent le message.
Étape 6 — Bloquer la soumission tant que les champs sont invalides
Empêchez l’envoi si la validation locale échoue. Permettez toutefois de lire une aide ou contacter le support.
Bonnes pratiques UX
- Affichez un exemple de format (MM/AA ou MM/YYYY) dans le placeholder.
- Proposez un bouton « Tester la carte » si votre parcours l’autorise : cela clarifie l’étape d’authentification et réduit les erreurs de saisie récurrentes.
Workflow 2 — Gestion d'un refus d'autorisation (statut de paiement négatif)
Étape 1 — Catégoriser le refus
Quand le prestataire retourne un refus, identifiez la catégorie : refus banque (paiement rejeté), solde insuffisant, suspicion de fraude, code d’erreur technique, ou refus d’authentification (3DS).
Étape 2 — Message utilisateur adapté
Affichez un message court et actionnable, par exemple :
- Refus classique : « Paiement refusé par la banque. Essayez une autre carte ou contactez votre banque. »
- Solde insuffisant : « Solde insuffisant. Utilisez une autre carte ou mode de paiement. »
- Suspicion de fraude : « Paiement bloqué pour sécurité. Contactez le support. » Ne montrez pas de codes bruts ni d’informations sensibles.
Étape 3 — Options proposées
Proposez : réessayer avec la même carte (si approprié), utiliser une autre carte, choisir un autre moyen de paiement, ou contacter le support avec la référence de l’opération.
Étape 4 — Limiter les tentatives automatiques
N’effectuez pas de réessais automatiques illimités. Préférez des tentatives contrôlées (voir stratégies de reprise) et informez l’utilisateur après X échecs pour éviter des blocages de banque.
Étape 5 — Journalisation et audit
Consignez le motif, la référence retournée par le prestataire et l’heure. Enregistrez uniquement des éléments non sensibles (réponse code, commentaire, numéro de référence, dernière4).
Étape 6 — Escalade et suivi
Si plusieurs refus successifs ou suspicion de fraude, ouvrez un ticket vers l’équipe support/risque avec la référence et la description lisible par le client.
Ne pas révéler trop d'informations
Ne transférez jamais au client des messages techniques de l’acquéreur ou du prestataire (codes d’erreur bruts, logs complets). Cela peut confondre l’utilisateur et exposer des données techniques sensibles.
Workflow 3 — Gestion des timeouts et erreurs réseau durant la transaction
Étape 1 — Détecter et afficher l'état
Si l’appel au prestataire dépasse le délai configuré, affichez un état « En cours — Vérification du paiement ». Évitez d’afficher « Échec » immédiatement.
Étape 2 — Options visibles pour l'utilisateur
Proposez : patienter, annuler la tentative, ou revenir à l’écran précédent pour changer de moyen de paiement. Donnez une estimation du délai restant si possible.
Étape 3 — Politique de réessai contrôlée
Après un timeout, appliquez une stratégie de réessai contrôlée (ex. 1 ou 2 réessais espacés) ; informez l’utilisateur que l’opération est en cours de vérification pour éviter re-soumissions.
Étape 4 — Vérifier l'absence de doublon
Avant de relancer une transaction, vérifiez si un retour transactionnel (référence, code autorisation) a déjà été reçu ou enregistré. Si oui, ne relancez pas ; utilisez la référence existante.
Étape 5 — Confirmation finale
Quand le prestataire confirme (success ou fail), notifiez l’utilisateur par l’interface et par mail si prévu. Si l’état reste indéterminé pendant trop longtemps, proposez un contact support avec la référence de suivi.
Conseil sécurité et UX
Si l’état est incertain, affichez un message rassurant et une action simple : « Nous vérifions votre paiement. Vous recevrez un e-mail dès que c’est confirmé. » Cela évite que l’utilisateur réessaye inutilement et crée des doublons.
Workflow 4 — Réception du retour transactionnel et enregistrement (action liée)
Étape 1 — Attendre le retour transactionnel
Après la tentative de paiement, attendez le retour final du prestataire (succès, refus, erreur technique). Ce retour contient la référence transactionnelle, le code d’autorisation et un code réponse lisible.
Étape 2 — Valider la cohérence
Vérifiez que la référence reçue correspond à la demande initiale (montant, identifiant de la demande) et que le statut est clair (success / declined / pending).
Étape 3 — Enregistrer uniquement les éléments non sensibles
Enregistrez dans l’inquiry/contrat uniquement :
- référence transactionnelle (numéro de confirmation),
- code d’autorisation,
- code réponse et commentaire lisible,
- date et heure,
- les 4 derniers chiffres de la carte (facultatif). N’enregistrez jamais le numéro de carte complet, l’expiration complète associée (si elle révèle la carte), ni le CVV.
Étape 4 — Mettre à jour le statut de paiement
Mettez à jour l’état de l’inquiry/contrat (payé, refusé, en attente) en vous basant sur le code réponse. Conservez un historique des tentatives et du statut.
Étape 5 — Notifier les parties prenantes
Envoyez une notification à l’utilisateur (e-mail/sms) et, si nécessaire, au service interne avec la référence transactionnelle et le statut. Fournissez des instructions en cas d’échec.
Étape 6 — Processus de vérification manuelle
Si l’opération est marquée comme « suspecte » ou incohérente, déclenchez un workflow de vérification manuelle (vérifier identité, demander justificatif) avant d’approuver définitivement.
Avant : stockage de données brutes (ex. numéro carte complet)
- Risque élevé de non-conformité.
- Surface d’attaque importante.
Après : stockage minimal (référence, autorisation, last4)
- Suffisant pour le support et la traçabilité.
- Respecte les principes PCI et réduit la responsabilité.
- Stop après 1 échec.
- Afficher message clair et inviter à réessayer manuellement.
- Avantage : évite doublons.
- Idéal pour transactions sensibles ou montant élevé.
Piège fréquent
Ne basez pas la réussite d’une commande uniquement sur l’affichage côté utilisateur. Assurez-vous d’avoir une trace transactionnelle (référence + statut) et d’attendre confirmation réelle avant de délivrer un service ou générer des documents contractuels.
Workflow 5 — Messages utilisateur : modèles et microcopy sécurisée
Étape 1 — Message en cas de succès
Court + utile : « Paiement accepté. Référence : 1234. Un e‑mail de confirmation a été envoyé. »
Étape 2 — Message en cas d'échec simple
Ex. « Paiement refusé. Veuillez réessayer avec une autre carte ou contacter votre banque. » Ajoutez une action : bouton « Réessayer » ou « Utiliser une autre carte ».
Étape 3 — Message en cas d'état incertain (timeout)
Ex. « Vérification en cours. Nous confirmons votre paiement dès que possible. Vous recevrez un e‑mail sous X minutes. » Donnez un contact support si besoin.
Étape 4 — Message en cas de suspicion de fraude
Ex. « Paiement bloqué pour raisons de sécurité. Contactez le support avec la référence suivante : 1234. » Ne révélez pas les raisons techniques exactes.
Étape 5 — Exemples de messages à éviter
- Pas : « Code erreur 05 : AVS mismatch » (trop technique).
- Pas : afficher le numéro de carte complet ou CVV.
Préférez un texte humain et actionnable.
Support & documentation interne
Fournissez à l’équipe support un guide interne listant les erreurs fréquentes, les significations business des codes et les actions recommandées (ex. « code X = réessayer, code Y = escalader »). Cela accélère les résolutions et offre une réponse cohérente aux clients.
Frequently Asked Questions
Checklist conformité et sécurité
- Ne pas stocker PAN complet ni CVV.
- Conserver uniquement last4, référence et code autorisation.
- Afficher des messages utilisateur dépourvus d’informations techniques.
- Limiter et documenter les réessais.
- Tenir un historique horodaté des tentatives et statuts.
Besoin d'aide pour votre parcours paiement ?
Si vous avez des cas particuliers (montants élevés, abonnements, paiements internationaux), contactez le support pour définir la stratégie de reprise et la conformité adaptée.