Résoudre les problèmes
Commandes non confirmées après un paiement avec Redsys
Ne marquez pas la commande comme payée parce que l'acheteur est revenu sur la boutique. La confirmation doit provenir de la notification de serveur à serveur de Redsys, validée par l'application.
Localiser d'abord la notification
- Recherchez l'opération dans le portail d'administration de Redsys par numéro de commande, commerçant et terminal.
- Vérifiez l'URL de notification configurée et son résultat exact. Notez l'heure et toute erreur.
- Rapprochez cette heure du journal d'accès du site et du journal du module de paiement. Un test depuis l'hébergement lui-même ne prouve pas que Redsys pouvait atteindre l'URL.
Configuration sécurisée de la notification
Utilisez une version maintenue de l'intégration Redsys pour PrestaShop, WooCommerce ou l'application concernée. Configurez l'URL de notification en HTTPS avec un certificat valide, comme mesure de sécurité de Hostsuar ; ne repassez pas le retour en HTTP pour masquer un échec. Si la notification n'arrive pas, vérifiez depuis un réseau externe l'URL, le certificat, la chaîne, le DNS, le pare-feu et les journaux du même instant.
L'application ne doit pas marquer une commande comme payée à la simple visite du client sur l'URL de retour. Avant de confirmer le paiement, le callback du serveur doit :
- Vérifier la signature cryptographique de Redsys avec la clé configurée et rejeter toute signature invalide.
- Vérifier que le numéro de commande, le commerçant, le terminal, la devise, le type d'opération et le montant exact correspondent à l'opération en attente enregistrée localement.
- Interpréter le code
Ds_Responseselon la table et le type d'opération de Redsys avant de changer le statut de la commande. - Empêcher les répétitions : enregistrez l'identifiant de l'opération et traitez chaque notification de façon idempotente, sans encaisser ni confirmer deux fois la même commande.
Passez une commande de test après avoir mis à jour ou changé le module et confirmez dans les journaux que la notification HTTPS et toutes ces validations se déroulent correctement.
Si Redsys affiche le paiement mais que la boutique ne le confirme pas
Ne demandez pas à l'acheteur de payer à nouveau sans vérifier l'opération. Contrôlez d'abord son résultat dans Redsys et le statut local pour éviter un second encaissement. Un HTTP 200 du callback ne prouve que sa réponse web ; le journal du module doit aussi confirmer la validation et le changement de statut.
Si le portail permet de renvoyer la notification, n'utilisez cette fonction qu'après avoir corrigé la cause et confirmé que l'intégration traite les répétitions sans dupliquer leurs effets. Ne construisez pas de notification manuelle et ne marquez pas la commande en vous fondant sur des paramètres de l'URL du navigateur.
Cette URL conserve la référence historique aux certificats SNI, mais un échec actuel ne doit pas être attribué au SNI sans une erreur TLS qui le démontre. Consultez la documentation d'intégration de Redsys et gardez séparés les clés et les environnements de test et de production ; n'incluez jamais la clé de signature dans un ticket ou une capture d'écran.
Cela peut aussi vous aider
- Comment résoudre l'erreur cURL 60 de certificat SSL dans WordPress Comment diagnostiquer et résoudre l'erreur cURL 60 de WordPress sans désactiver la vérification des...
- Activer la journalisation et l'affichage des erreurs PHP Enregistrez les erreurs PHP dans un fichier error_log ou affichez-les à l'écran pour trouver la caus...
- Activer le journal des erreurs PHP depuis le fichier .htaccess Configurez .htaccess pour enregistrer temporairement les erreurs PHP en dehors de public_html, sans...
- Activer temporairement le mode debug de PrestaShop Obtenez l'exception exacte en activant temporairement _PS_MODE_DEV_ depuis le back-office ou defines...
Quelque chose cloche ou a changé ? Racontez-nous et nous le vérifions.