Comment accepter des paiements avec Stripe sur un site créé avec une IA ?

Stripe Checkout : qui affiche la page de paiement ?

Pour encaisser dix euros par carte, il faut un formulaire qui recueille un numéro, une date d’expiration et un cryptogramme. Votre IA saurait en dessiner un, et c’est justement ce qu’il vaut mieux ne pas lui demander, car un site qui voit passer des numéros de carte hérite des obligations de sécurité qui les accompagnent. Stripe est un prestataire de paiement : il encaisse pour vous, et Checkout est la page de paiement qu’il héberge chez lui. Le client y saisit sa carte, puis revient sur votre site, qui n’a rien vu de ces données.

Encore faut-il indiquer à Stripe ce que ce client doit régler. Si le bouton annonçait lui-même « vingt devis, dix euros », un visiteur curieux pourrait remplacer dix par un, puisque tout ce qui s’exécute dans un navigateur peut être modifié par celui qui s’en sert. Le bouton ne transmet donc que le nom du produit à votre serveur, la partie de votre application qui tourne chez votre hébergeur, là où les visiteurs ne peuvent rien modifier. C’est le serveur qui reconnaît le compte connecté, fixe le prix et demande à Stripe une session de paiement, c’est-à-dire une page valable pour cet achat précis.

Avant de laisser partir le client, le serveur note aussi cet achat de son côté, et c’est là qu’intervient la base de données.

Documentation Stripe : Checkout, page hébergée pas à pas et guide de sécurité.

Que garde Stripe, et que doit retenir votre base de données ?

Stripe sait qu’une carte a payé dix euros. Il ignore en revanche ce qu’est un devis, combien il en reste à tel utilisateur et à quel compte rattacher ce paiement. Ces informations vivent chez vous, dans votre base de données : l’endroit où l’application range ce qu’elle doit retrouver d’une visite à l’autre, dans des tables dont chaque ligne décrit un compte, un achat ou un droit.

Trois tables suffisent pour notre pack. Celle des comptes existe déjà, et chacun y porte un identifiant, un numéro attribué une fois pour toutes, plus sûr comme repère qu’une adresse e‑mail qui peut changer. Celle des commandes est nouvelle : avant d’envoyer le client chez Stripe, le serveur y inscrit une ligne « en attente », avec son propriétaire, le produit, le montant attendu et la référence de la session. Celle des droits indique ce que chaque compte peut faire, ici le nombre de devis qui lui restent.

Aucune de vos tables ne contient de numéro de carte ni de cryptogramme, et si votre agent vous en propose une, refusez. Stripe ne remplace pas davantage la connexion à votre site : l’adresse e‑mail de facturation qu’il conserve sert à envoyer des reçus et n’ouvre aucun compte chez vous.

Documentation Stripe : données de carte que vous pouvez conserver et références à vos propres identifiants.

Comment savoir qu’un paiement Stripe est vraiment confirmé ?

La commande attend dans votre base pendant que le client paie. Lorsqu’il a terminé, Stripe le renvoie vers une page de votre site, la page « Merci », et la tentation est grande d’y créditer les vingt devis. Or cette page ne prouve rien : le client peut avoir payé puis perdu sa connexion avant qu’elle ne s’affiche, et l’adresse de cette page peut à l’inverse être ouverte par quelqu’un qui n’a rien réglé.

La preuve arrive par un autre chemin. Lorsque le paiement est confirmé, Stripe écrit de lui-même à votre serveur, sans passer par le navigateur du client : c’est un webhook, une notification qu’un service envoie à un autre lorsqu’un événement se produit. L’adresse qui la reçoit étant publique, n’importe qui peut y déposer un faux « le compte 42 a payé » ; Stripe signe donc ses messages à l’aide d’un secret partagé avec votre serveur, qui écarte tout message dont la signature ne correspond pas.

Une fois la signature vérifiée, le serveur relit auprès de Stripe l’état de la session avant d’écrire quoi que ce soit. La page « Merci » peut lancer cette même vérification pour que le client voie son crédit sans attendre, mais elle se borne alors à interroger le serveur. Quant aux paiements qui aboutissent plusieurs jours plus tard, comme le prélèvement bancaire, ils laissent la commande « en attente » jusqu’à leur confirmation.

Documentation Stripe : accorder un achat après le paiement et recevoir et vérifier les webhooks.

Que se passe-t-il si Stripe prévient deux fois ?

Ce chemin a une particularité qu’il vaut mieux connaître avant qu’elle ne vous coûte de l’argent : la même notification peut arriver plusieurs fois. Si votre serveur tarde à répondre, Stripe recommence, pendant trois jours au besoin, et la page « Merci » lance de son côté la même vérification. Un code qui ajouterait vingt devis à chaque demande transformerait alors un pack à dix euros en quarante ou soixante devis.

La parade tient en deux règles, que vous faites appliquer par la base elle-même. La première réunit le passage de la commande à « payée » et l’ajout des devis dans une seule opération, exécutée en entier ou pas du tout : c’est une transaction. Elle s’ouvre sur une transition conditionnelle, « passe cette commande à payée si elle est encore en attente », ou sur un verrou posé sur la commande ; dans les deux cas, la base ne laisse passer qu’un seul traitement, qui crédite les devis, tandis que les autres, même arrivés au même instant, trouvent la commande déjà payée et s’arrêtent. La seconde est une contrainte d’unicité sur la référence de la session Stripe, par laquelle la base refuse d’enregistrer deux commandes pour le même paiement.

Les développeurs disent d’un tel traitement qu’il est idempotent : on peut le rejouer autant de fois qu’on veut, le résultat reste celui de la première fois. Vous saurez ainsi quoi vérifier le jour où votre agent vous assurera que « c’est géré ».

Chez Stripe, doublons et ordre des notifications ; chez PostgreSQL, une base de données très répandue, transactions et contraintes d’unicité.

Qui a le droit de créer un devis ?

Les vingt devis figurent maintenant dans la table des droits, et il reste à les consulter au bon endroit. Lorsque le client clique sur « Créer le devis », c’est le serveur qui vérifie qu’il lui reste un crédit, le décompte et produit ensuite le document. Masquer le bouton aux comptes sans crédit ne protège rien, car la demande peut être adressée au serveur sans passer par lui.

Ce contrôle répond à deux questions que l’on confond volontiers. L’authentification établit qui fait la demande, l’autorisation ce que cette personne a le droit de faire : un utilisateur connecté n’a pas pour autant le droit de consulter la commande d’un autre. Le serveur doit donc vérifier, à chaque demande qui lit ou modifie une commande ou un solde de devis, que le compte connecté en est le propriétaire, sans quoi il suffirait de changer un numéro dans l’adresse pour lire les achats du voisin.

Référence : fiche de l’OWASP sur l’autorisation.

Comment gérer un abonnement, une résiliation ou un remboursement ?

Supposons que vous proposiez aussi une formule Premium à dix euros par mois, avec des devis à volonté. Le paiement revient désormais chaque mois sans que le client passe par votre site, et les notifications de Stripe permettent à votre serveur de suivre ces paiements sans attendre une visite. Le droit change lui aussi de forme : à la place d’un nombre de crédits, la table retient une échéance, la date jusqu’à laquelle l’accès reste ouvert, reprise de la fin de période que Stripe indique pour l’abonnement plutôt que calculée à la main.

Le serveur compare cette date au jour présent à chaque devis demandé. Ne laissez pas votre agent ranger dans la base un simple « Premium : oui », car une case cochée ne se décoche jamais toute seule, et vos abonnés partis depuis un an continueraient de dicter leurs devis à vos frais. Lorsqu’un prélèvement échoue, Stripe peut le retenter ; il vous revient de décider si l’accès reste ouvert quelques jours ou se ferme aussitôt.

Pour changer de carte ou résilier, vous n’avez pas d’écrans à construire : Stripe fournit un portail client, une page hébergée chez lui. Votre serveur identifie l’abonné, retrouve dans sa base le client Stripe associé à son compte et ouvre le portail pour ce client-là, sans se fier à un identifiant envoyé par le navigateur. Une résiliation programmée pour la fin de la période laisse l’accès ouvert jusqu’à l’échéance déjà payée.

Un remboursement est une autre opération, qui rend de l’argent sans arrêter l’abonnement. Pour le pack, c’est à vous de fixer la règle, par exemple retirer les devis non utilisés, et à votre serveur de l’appliquer une fois le remboursement abouti, puisqu’une demande peut rester en attente ou échouer.

Documentation Stripe : abonnements et notifications, portail client et remboursements.

Comment tester Stripe sans encaisser un centime ?

Rien de tout cela ne s’essaie avec votre propre carte. Stripe fournit un bac à sable, ou sandbox : une copie de votre compte où les paiements sont simulés, avec ses propres clés d’accès et des numéros de carte fictifs prévus pour réussir, être refusés ou réclamer une validation de la banque.

Cette séparation ne concerne toutefois que Stripe. Si votre site d’essai écrit dans la base de vos vrais clients, un paiement simulé y créditera de vrais comptes ; il lui faut donc sa propre base, comme la copie d’essai décrite dans notre guide sur GitHub.

Dans ce circuit d’essai, jouez les situations qui fâchent, en regardant chaque fois le résultat dans votre application.

Les clés d’accès, ces codes par lesquels votre site s’identifie auprès de Stripe, demandent la même rigueur. Celle en pk_ peut figurer dans le navigateur ; celles en sk_ ou rk_ et le secret de signature whsec_ restent dans les réglages de votre hébergeur, jamais dans le code, dans le dépôt Git ni dans une conversation avec une IA. Stripe recommande les clés restreintes, en rk_, limitées aux opérations utiles, et permet de signaler celle que vous confiez à un agent pour que ses actions sensibles attendent l’approbation d’une personne.

Reste la sauvegarde : l’historique Git conserve votre code et ignore tout de vos commandes. Si la base disparaît, vous ne savez plus qui a payé ni ce que vous lui devez ; demandez à votre agent comment elle est sauvegardée, et essayez au moins une fois de la restaurer.

Documentation Stripe : cartes d’essai, bacs à sable, essais d’abonnement et clés d’accès. Documentation PostgreSQL : sauvegarde et restauration.

Combien coûte Stripe sur un paiement de 10 € ?

Sur les dix euros du pack, tout ne vous revient pas : en France, au 9 octobre 2026, Stripe affiche pour une carte européenne standard une commission de 1,5 % du montant, augmentée de 0,25 € par paiement, sans frais d’installation ni abonnement mensuel.

Ces 9,60 € ne sont pas encore un bénéfice, puisqu’il reste à en déduire, selon votre situation, la TVA et vos propres charges. La commission dépend aussi de la carte : 2,8 % pour une carte européenne dite premium, 2,5 % pour une carte britannique et 3,15 % pour les autres cartes internationales, toujours avec 0,25 €.

Deux services se paient en plus. Les abonnements passent par Stripe Billing, facturé 0,7 % des montants qu’il traite : la mensualité Premium de dix euros coûte ainsi 0,40 € de paiement et 0,07 € de Billing. Stripe Tax, qui calcule la taxe à appliquer à chaque vente, coûte 0,5 % par transaction dans sa formule sans code ; ce pourcentage rémunère l’outil, sans rapport avec le taux de TVA, et ne règle pas à votre place vos obligations fiscales. Enfin, Stripe conserve sa commission lorsque vous remboursez un client : un pack remboursé vous coûte 0,40 €.

Tarifs relevés le 9 octobre 2026 sur les pages France de Stripe Payments, Stripe Billing et Stripe Tax.

Ce que vous pouvez demander à votre IA

Lisez la consigne qui suit avant de la coller à votre agent, puisque vous en connaissez maintenant chaque terme, puis servez-vous-en comme d’une liste de contrôle.

Je vends aux comptes déjà inscrits un pack de 20 devis pour 10 €. Avant d’écrire du code, explique-moi où sont rangés les comptes et leur solde de devis, puis propose les tables des commandes et des droits.

Utilise la page hébergée Stripe Checkout, dans un bac à sable, avec une base d’essai séparée de la production. Le serveur identifie le compte connecté, fixe lui-même le prix et enregistre une commande en attente avant de rediriger vers Stripe. N’enregistre aucun numéro de carte.

N’accorde les devis qu’après une notification Stripe dont la signature est vérifiée sur le corps brut de la requête et un paiement confirmé, dans une seule transaction et une seule fois par commande, même si la notification arrive deux fois. Vérifie le solde côté serveur à chaque devis demandé, et que chaque commande n’est visible que par son propriétaire.

Ne me demande aucune clé dans cette conversation : indique-moi les variables à créer chez l’hébergeur. Pour chaque protection, montre-moi le code qui l’applique et le test qui la vérifie, sans rien affirmer que tu ne puisses montrer. Donne-moi la liste des essais qu’il me reste à faire à la main, puis attends mon accord avant tout passage aux paiements réels.

Faites ensuite les essais vous-même, et faites relire par une personne compétente le code qui touche aux paiements. Avant d’accepter les paiements réels, Stripe vous demandera de vérifier votre activité et de choisir le libellé qui figurera sur le relevé bancaire de vos acheteurs. Pour que ces règles vaillent aussi pour les modifications suivantes, rangez-les dans le fichier que l’agent lit en démarrant, comme l’explique notre guide Markdown (.md).