Checklist avant de passer les paiements en LIVE : du mode test à la production sans erreur

Vous avez construit le tunnel de paiement, teste avec les cartes de test, et tout fonctionne parfaitement. Puis vous basculez en "live", et c'est la que les vrais problèmes commencent : le paiement passe mais l'argent n'arrive jamais, le webhook ne confirme pas la commande, ou le client est debite deux fois. En mode test, rien de tout cela ne fait mal. En production, chaque erreur est de l'argent perdu ou un client mécontent.

La différence entre test et live n'est pas un simple interrupteur. Il y a des clés distinctes, un compte à vérifier entièrement, des webhooks séparés et une série d'obligations légales qui, dans l'UE, sont impératives. Voici la checklist que nous parcourons avant chaque lancement de paiements, dans l'ordre qui compte. Ce n'est pas de la théorie : ce sont exactement les points qui cassent le plus souvent.

1. Clés live, compte active, plus rien de test dans le code

Premier piège : les clés. Dans Stripe (et presque tous les processeurs), vous avez un jeu de clés de test et un jeu de clés live, totalement séparés. Les données ne passent pas de l'un à l'autre — commandes, clients et abonnements du test n'existent pas en live.

À vérifier :

• La clé live est dans des variables d'environnement, PAS écrite en dur et PAS poussée sur Git.
• Vous l'avez remplacee partout : frontend (clé publique), backend (clé secrète), et tout service connecte.
• Le compte est entièrement active : informations société, compte bancaire pour les virements, vérification d'identite (KYC) terminée. Sans cela, vous encaissez mais ne pouvez pas retirer.
• Vous avez retire les boutons, produits et prix de test de la page live.

Un seul `sk_test_` oublié, et les paiements semblent fonctionner mais n'encaissent rien de réel.

2. Les webhooks : là ou la plupart des paiements cassent

L'erreur la plus fréquente au lancement : le webhook de test reste, tandis que celui de production manque ou a le mauvais secret. Le résultat est brutal — le client paie, l'argent arrive chez le processeur, mais votre site ne le sait jamais, donc la commande reste non confirmée.

À vérifier :

• Vous avez cree un endpoint de webhook SÉPARÉ pour le mode live, avec son propre secret de signature.
• Vous vérifiez la signature de chaque événement avant de le traiter (sinon n'importe qui peut vous simuler un paiement).
• Vous traitez les événements de manière idempotente : le même événement peut arriver deux fois, et votre code ne doit pas honorer la commande deux fois.
• Vous vous fiez au webhook pour la confirmation finale, pas à la redirection du navigateur — l'utilisateur peut fermer l'onglet avant de revenir.

Testez-le avec un vrai paiement, pas seulement le simulateur.

3. Montants, devise et TVA : des erreurs qui coûtent au centime

La plupart des processeurs travaillent dans la plus petite unite de la devise. 100 euros ne s'envoie pas comme "100" mais comme 10000 (centimes). C'est une erreur classique d'afficher correctement sur la page mais d'envoyer le montant multiplie ou divise de travers — et c'est le client qui vous signale qu'il a été debite du mauvais montant.

À vérifier :

• Les montants sont calcules cote serveur, jamais repris du prix envoyé par le navigateur (n'importe qui peut le modifier).
• La devise est correcte et cohérente partout.
• La TVA est incluse et clairement affichée, et le prix final au checkout correspond à la fiche produit.
• Vous utilisez des clés d'idempotence à la création du paiement, pour qu'un double-clic ne cree pas deux debits.

Une transaction de test avec un montant reel montre immédiatement si les chiffres tiennent.

4. 3D Secure, SCA et ce qui se passe quand un paiement échoue

Dans l'UE, l'authentification forte (SCA / 3D Secure) est obligatoire pour la plupart des paiements par carte. En mode test, les cartes de test passent souvent sans l'étape de confirmation de la banque. En production, le vrai client reçoit un SMS ou une notification de son application bancaire — et si votre flux ne gere pas cette étape, le paiement semble se "bloquer".

À vérifier :

• Le checkout gere l'étape d'authentification 3D Secure et attend son résultat.
• Vous avez des états d'échec clairs : carte refusée, fonds insuffisants, authentification abandonnée — avec des messages que le client comprend.
• Le client peut réessayer sans perdre son panier.
• Les remboursements fonctionnent : testez-en un pour de vrai, pour savoir à quoi cela ressemble quand vous en aurez vraiment besoin.

Un checkout sans états d'erreur perd des clients en silence.

5. Le volet légal : sans lui, le paiement n'est pas complet

Un checkout qui fonctionne techniquement mais dont les documents ne sont pas en place vous expose aux réclamations et aux amendes. Le commerce en ligne à des exigences claires.

À vérifier :

• Conditions générales, Politique de confidentialité (RGPD) et Politique de retour, accessibles depuis le checkout.
• Prix affichés TVA incluse.
• Coordonnées de l'entreprise visibles (nom, numéro d'immatriculation, siège, contact).
• Le cas échéant, le lien vers la plateforme européenne de règlement des litiges et l'information consommateur.
• Une facture emise automatiquement après le paiement — connectez votre checkout à un système de facturation dès le départ plutôt que de rattraper plus tard.

Cela ressemble à de la bureaucratie jusqu'à la première réclamation. Réglez-le une fois, bien, et vous n'y pensez plus.

6. Le test final : une vraie transaction, puis un remboursement

La dernière étape avant de vous declarer en live : faites vous-même un vrai paiement, avec votre carte, pour un petit montant. C'est la seule façon de voir toute la chaîne fonctionner ensemble — checkout, 3D Secure, webhook, confirmation de commande, e-mail, facture, et l'argent qui apparaît sur votre compte de virement.

Ensuite, remboursez cette même transaction et vérifiez que le retour se fait proprement. Si tout cela s'enchaine une fois, vous êtes prêt.

Chez MPO Web Studio, nous construisons des sites avec paiements intégrés, à distance, partout dans le pays, et nous parcourons exactement ce chemin de mise en production avec le client — avec une démo prête avant même de payer quoi que ce soit. Si vous voulez qu'on passe cette checklist sur votre site avant le lancement, écrivez-nous sur WhatsApp et on la deroule étape par étape.