Une commande payée
qui reste « en attente ».
Brancher Stripe sur PrestaShop prend une heure. Ce qui prend du temps, c'est de rendre le tunnel fiable dans les cas où le client ne se comporte pas comme prévu — il revient en arrière, il double-clique, sa session expire pendant la validation 3DS. Chacun de ces cas produit soit une commande en double, soit une commande payée que la boutique croit impayée.
Le point central s'appelle le webhook. Quand un paiement aboutit, Stripe prévient votre boutique par un appel serveur à serveur, indépendant du navigateur du client. Si ce webhook n'est pas configuré, ou s'il échoue en silence, la commande reste dans un état intermédiaire alors que l'argent est encaissé — et vous ne le découvrez qu'en rapprochant les relevés.
Lire la suite
C'est de loin le défaut le plus fréquent que je trouve sur les boutiques déjà en ligne, et il ne se voit jamais depuis le back-office. Le deuxième sujet est l'idempotence, c'est-à-dire le fait qu'une même action répétée ne produise qu'un seul effet. Un client qui double-clique sur « Payer », ou qui revient en arrière puis revalide, ne doit pas créer deux commandes ni être débité deux fois.
Cela se traite côté PrestaShop, pas côté Stripe, et cela se teste — en reproduisant réellement ces gestes, pas en supposant qu'ils n'arrivent pas. Le reste est de la configuration bien faite : 3DS2 conforme, ce qui n'est plus optionnel en Europe ; paiement en plusieurs fois si votre panier moyen le justifie ; abonnements pour les offres récurrentes, avec la gestion des échecs de prélèvement — une carte expirée doit relancer le client, pas résilier en silence. Et le rapprochement : chaque commande doit pouvoir être retrouvée dans Stripe, et réciproquement, sinon la comptabilité devient une enquête.
Ce que vous obtenez.
Comment on procède.
État des lieux
Sur une boutique existante : webhooks, états de commande, commandes orphelines des trois derniers mois. C'est souvent là que la surprise arrive.
Intégration
Configuration, 3DS2, moyens de paiement, et les états de commande qui déclenchent les bons emails et les bons mouvements de stock.
Tests de rupture
On reproduit les gestes qui cassent : double clic, retour, fermeture d'onglet pendant 3DS, carte refusée, réseau coupé.
Paiements réels
Quelques commandes réelles de bout en bout avant ouverture, remboursées ensuite. Les tests en environnement de test ne voient pas tout.
Questions fréquentes
Pages liées.
Prêt pour votre projet ?
Devis gratuit sous 48h. Réponse sous 24h. Aucun engagement.
Certification délivrée par l'éditeur du CMS