Checklist avant de passer les paiements en LIVE : du mode test a 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 problemes 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 mecontent.

La difference entre test et live n'est pas un simple interrupteur. Il y a des cles distinctes, un compte a verifier entierement, des webhooks separes et une serie d'obligations legales 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 theorie : ce sont exactement les points qui cassent le plus souvent.

1. Cles live, compte active, plus rien de test dans le code

Premier piege : les cles. Dans Stripe (et presque tous les processeurs), vous avez un jeu de cles de test et un jeu de cles live, totalement separes. Les donnees ne passent pas de l'un a l'autre — commandes, clients et abonnements du test n'existent pas en live.

A verifier :

• La cle live est dans des variables d'environnement, PAS ecrite en dur et PAS poussee sur Git.
• Vous l'avez remplacee partout : frontend (cle publique), backend (cle secrete), et tout service connecte.
• Le compte est entierement active : informations societe, compte bancaire pour les virements, verification d'identite (KYC) terminee. 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_` oublie, et les paiements semblent fonctionner mais n'encaissent rien de reel.

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

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

A verifier :

• Vous avez cree un endpoint de webhook SEPARE pour le mode live, avec son propre secret de signature.
• Vous verifiez la signature de chaque evenement avant de le traiter (sinon n'importe qui peut vous simuler un paiement).
• Vous traitez les evenements de maniere idempotente : le meme evenement 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 a 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 coutent 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 ete debite du mauvais montant.

A verifier :

• Les montants sont calcules cote serveur, jamais repris du prix envoye par le navigateur (n'importe qui peut le modifier).
• La devise est correcte et coherente partout.
• La TVA est incluse et clairement affichee, et le prix final au checkout correspond a la fiche produit.
• Vous utilisez des cles d'idempotence a la creation du paiement, pour qu'un double-clic ne cree pas deux debits.

Une transaction de test avec un montant reel montre immediatement si les chiffres tiennent.

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

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'etape de confirmation de la banque. En production, le vrai client recoit un SMS ou une notification de son application bancaire — et si votre flux ne gere pas cette etape, le paiement semble se "bloquer".

A verifier :

• Le checkout gere l'etape d'authentification 3D Secure et attend son resultat.
• Vous avez des etats d'echec clairs : carte refusee, fonds insuffisants, authentification abandonnee — avec des messages que le client comprend.
• Le client peut reessayer sans perdre son panier.
• Les remboursements fonctionnent : testez-en un pour de vrai, pour savoir a quoi cela ressemble quand vous en aurez vraiment besoin.

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

5. Le volet legal : 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 reclamations et aux amendes. Le commerce en ligne a des exigences claires.

A verifier :

• Conditions generales, Politique de confidentialite (RGPD) et Politique de retour, accessibles depuis le checkout.
• Prix affiches TVA incluse.
• Coordonnees de l'entreprise visibles (nom, numero d'immatriculation, siege, contact).
• Le cas echeant, le lien vers la plateforme europeenne de reglement des litiges et l'information consommateur.
• Une facture emise automatiquement apres le paiement — connectez votre checkout a un systeme de facturation des le depart plutot que de rattraper plus tard.

Cela ressemble a de la bureaucratie jusqu'a la premiere reclamation. Reglez-le une fois, bien, et vous n'y pensez plus.

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

La derniere etape avant de vous declarer en live : faites vous-meme un vrai paiement, avec votre carte, pour un petit montant. C'est la seule facon de voir toute la chaine fonctionner ensemble — checkout, 3D Secure, webhook, confirmation de commande, e-mail, facture, et l'argent qui apparait sur votre compte de virement.

Ensuite, remboursez cette meme transaction et verifiez que le retour se fait proprement. Si tout cela s'enchaine une fois, vous etes pret.

Chez MPO Web Studio, nous construisons des sites avec paiements integres, a distance, partout dans le pays, et nous parcourons exactement ce chemin de mise en production avec le client — avec une demo prete avant meme de payer quoi que ce soit. Si vous voulez qu'on passe cette checklist sur votre site avant le lancement, ecrivez-nous sur WhatsApp et on la deroule etape par etape.