Pour ajouter des paiements Stripe à une application créée avec l'IA, choisissez le produit Stripe qui correspond à ce que vous vendez (un Payment Link, Checkout, ou Checkout avec abonnement), gardez la clé secrète Stripe sur le serveur dans une edge function, et laissez un webhook, pas la page de succès, écrire le statut « payé » dans votre base de données. Testez ensuite tout en mode test de Stripe avant de passer en production. Un créateur d'app IA peut écrire tout le code, mais il faut lui préciser ces décisions, une étape à la fois.
Ce guide couvre les trois options Stripe, la configuration côté serveur, le webhook, le portail client, les tests et les prompts exacts à envoyer. Pour le contexte plus large de la création de l'app elle-même, lisez notre guide pour créer une application avec l'IA.
Payment Links, Checkout ou abonnements : lequel choisir
Utilisez un Payment Link quand vous vendez quelque chose de simple et que votre app n'a pas besoin de réagir en temps réel, utilisez Checkout quand votre app décide du montant à facturer et de qui paie, et utilisez une session Checkout en mode abonnement quand l'accès dépend d'une formule récurrente. D'après la documentation Stripe sur les Payment Links, un Payment Link est une page hébergée par Stripe que vous créez sans code et partagez par lien, QR code ou bouton d'achat intégrable. Il peut vendre un produit, un abonnement ou recevoir des dons, avec une personnalisation visuelle limitée.
Checkout est le même type de page de paiement, mais c'est votre code qui la crée via l'API Checkout Sessions, comme le décrit la documentation Stripe sur Checkout. C'est ce qui permet à votre app de rattacher le paiement à un utilisateur connecté, de choisir le prix depuis votre base de données et de renvoyer le client vers le bon écran. Checkout peut être une page hébergée par Stripe ou un formulaire intégré à votre site.
| Option | Code nécessaire | Sait quel utilisateur a payé | Idéale pour | Principale limite |
|---|---|---|---|---|
| Payment Link | Aucun pour le créer | Seulement en rapprochant l'e-mail ou un paramètre d'URL après coup | Une première vente, un produit unique, un don, une prévente | Personnalisation limitée ; votre app n'est pas dans la boucle sans webhook |
| Checkout (paiement unique) | Une fonction serveur | Oui, vous transmettez l'id de l'utilisateur à la création de la session | Achat de crédits, rapport payant, acompte de réservation | Vous maintenez la fonction et le webhook |
| Checkout (mode abonnement) | Une fonction serveur et la gestion des webhooks | Oui | Formules SaaS, adhésions, tout ce qui est facturé chaque mois ou chaque année | Renouvellements, paiements échoués et résiliations arrivent plus tard et doivent être traités |
La clé secrète ne va jamais dans le navigateur
La clé secrète Stripe ne doit vivre que sur un serveur, car quiconque la détient peut créer des paiements, émettre des remboursements et lire les données clients. Tout ce dont le navigateur a besoin, c'est d'une URL Checkout de courte durée que votre serveur renvoie après avoir appelé Stripe. Un créateur d'app IA qui met la clé secrète dans un fichier React a rendu l'app dangereuse : c'est la première chose à vérifier dans tout code de paiement généré.
Le modèle standard est une edge function, un petit morceau de code serveur qui s'exécute à côté de votre base de données. Le navigateur l'appelle avec la connexion de l'utilisateur, la fonction vérifie qui il est, crée la session Checkout avec la clé secrète et renvoie l'URL. La clé elle-même est stockée dans une variable d'environnement, jamais dans le code. Notre guide sur la sécurité du vibe coding liste les autres contrôles à faire sur le code généré.
Pourquoi la base de données se met à jour depuis le webhook, pas depuis la page de succès
Marquez une commande comme payée uniquement quand Stripe vous le signale par un webhook, jamais quand le client arrive sur votre page de succès. La page de succès n'est qu'un onglet de navigateur : il peut être fermé avant de s'afficher, ouvert par quelqu'un qui a tapé l'adresse, ou jamais atteint parce que la connexion du client a coupé après le paiement. Un webhook, c'est Stripe qui appelle directement votre serveur, et la documentation Stripe sur les webhooks le présente comme le moyen de réagir à des événements asynchrones : une banque qui confirme un paiement, un litige, ou un paiement récurrent qui aboutit.
Un gestionnaire de webhook doit avoir quatre propriétés :
- Il vérifie la signature. Chaque requête porte un en-tête
Stripe-Signature. Le gestionnaire le contrôle avec le secret de votre point de terminaison, de sorte qu'un inconnu qui envoie de faux événements « payé » est rejeté. L'horodatage contenu dans l'en-tête limite aussi les rejeux. - Il répond vite avec un code de succès. Stripe attend une réponse 2xx. En mode live, il réessaie une livraison échouée pendant jusqu'à trois jours avec des délais croissants ; en mode test, il fait trois tentatives sur quelques heures.
- Il peut s'exécuter deux fois sans risque. Avec les nouvelles tentatives, un même événement peut arriver plusieurs fois. Stockez l'id de l'événement, ou écrivez le statut de façon à obtenir le même résultat à la seconde exécution.
- Il est joignable sans connexion utilisateur. Stripe n'est pas un utilisateur connecté de votre app : cette fonction doit donc accepter les requêtes sans votre contrôle de connexion habituel, et s'appuyer sur la signature à la place.
Ce qu'il faut stocker dans la base de données
Stockez l'id client Stripe, l'id d'abonnement, la formule et le statut de l'abonnement à côté de chaque utilisateur, et ne les mettez à jour que depuis les événements du webhook. Votre app lit alors une seule ligne locale pour décider de ce qu'un utilisateur peut faire, sans appeler Stripe à chaque page. Pour les abonnements, le guide Stripe sur les webhooks d'abonnement liste les événements et les statuts à gérer :
| Signal Stripe | Ce que cela signifie | Ce que fait votre app |
|---|---|---|
invoice.paid | Une facture, renouvellement compris, a été payée | Accorder ou prolonger l'accès (Stripe conseille de vérifier d'abord que le statut de l'abonnement est actif) |
invoice.payment_failed | Une tentative de paiement a échoué | Prévenir le client et lui demander de mettre à jour sa carte |
customer.subscription.updated | La formule, le renouvellement ou le statut a changé | Copier la nouvelle formule et le nouveau statut dans votre table |
customer.subscription.deleted | L'abonnement est terminé | Retirer l'accès payant |
Statut past_due | Le dernier paiement a échoué, Stripe peut réessayer | Prévenir le client ; décider combien de temps garder l'accès |
Statut canceled ou unpaid | Ne paie plus | Révoquer l'accès, selon les conseils de Stripe |
Comme les utilisateurs lisent leur propre formule dans cette table, elle a besoin de la row level security : un utilisateur peut lire sa propre ligne et personne ne peut y écrire depuis le navigateur. Seule la fonction webhook, qui s'exécute avec une clé côté serveur, écrit. Notre guide sur la row level security de Supabase explique la politique.
Laissez les clients résilier via le portail client
Utilisez le portail client de Stripe pour les résiliations, les changements de carte et les factures plutôt que de construire ces écrans. D'après la documentation Stripe sur le portail client, les clients peuvent mettre à jour leurs informations de facturation et leurs moyens de paiement, changer ou suspendre un abonnement, résilier immédiatement ou à la fin de la période de facturation, et consulter ou payer leurs factures. Vous le configurez dans le tableau de bord Stripe.
Votre app n'a besoin que d'un bouton, « Gérer la facturation », qui appelle une seconde edge function. La fonction crée une session de portail pour l'id client Stripe de l'utilisateur connecté et renvoie une URL. Deux limites de la même page comptent : le portail ne peut pas s'afficher dans une iframe, et le lien d'une nouvelle session expire au bout de 5 minutes ; créez-le donc au moment du clic, pas à l'avance. Les résiliations faites là-bas arrivent dans votre base de données par les mêmes événements de webhook, donc aucun code supplémentaire n'est nécessaire.
Mode test et cartes de test
Testez tout avec les clés de test de Stripe avant de toucher au mode live, car les environnements de test sont isolés et ne déplacent aucun argent réel. Selon le guide de test de Stripe, il ne faut jamais utiliser de vraies coordonnées de carte pour tester. Voici les cartes à essayer :
| Scénario | Numéro de carte |
|---|---|
| Paiement réussi | 4242 4242 4242 4242 |
| Refus générique | 4000 0000 0000 0002 |
| Fonds insuffisants | 4000 0000 0000 9995 |
| 3D Secure, à authentifier sauf si déjà configuré | 4000 0025 0000 3155 |
Pour la date d'expiration, utilisez n'importe quelle date future, pour le CVC trois chiffres au choix, et une valeur quelconque pour les autres champs. Exécutez au moins quatre scénarios : un paiement réussi, une carte refusée, une résiliation depuis le portail et un webhook livré deux fois. Vérifiez la ligne de la base de données après chacun.
Frais, taxes et factures
Les frais standard de Stripe pour une carte sont un pourcentage de chaque paiement plus un montant fixe, et les deux varient selon le pays : consultez le chiffre de votre pays sur stripe.com/pricing avant de fixer vos prix. Nous n'avons pas trouvé de tarif américain sur les pages que nous avons pu lire en novembre 2026, donc nous n'indiquons aucun frais de carte ici. La même page présente Billing, le produit d'abonnement, comme un coût distinct sur le volume récurrent (0,7 % en paiement à l'usage, vérifié en novembre 2026 sur la page de tarifs française), et Stripe Tax comme une autre ligne facultative.
En résumé : Checkout et les Payment Links prennent tous deux en charge Stripe Tax, qui calcule pour vous la taxe sur les ventes ou la TVA, et Stripe peut envoyer automatiquement reçus et factures. Savoir si vous devez vous immatriculer et collecter la taxe dépend de l'endroit où vous et vos clients vous trouvez : demandez à un comptable avant le lancement plutôt qu'à un créateur d'app IA.
Les prompts à envoyer, une étape à la fois
Envoyez ces prompts dans l'ordre et vérifiez chaque résultat avant le suivant : un seul prompt qui demande paiements, webhooks et portail à la fois produit du code difficile à déboguer. Créez d'abord votre compte Stripe, un produit et un prix en mode test, et gardez l'id du prix sous la main. Remplacez les éléments entre [crochets].
- Checkout. « Ajoute une page Tarifs avec une formule [Pro] à [19 $ par mois]. Le bouton S'abonner appelle une fonction serveur qui vérifie que l'utilisateur est connecté, crée une session Stripe Checkout en mode abonnement pour l'id de prix [price_xxx] avec l'id de l'utilisateur attaché, et renvoie l'URL. Redirige le navigateur vers cette URL. La clé secrète Stripe ne doit être utilisée que dans cette fonction. »
- Base de données. « Crée une table subscriptions avec l'id utilisateur, l'id client Stripe, l'id d'abonnement, la formule, le statut et la fin de la période en cours. Ajoute la row level security pour qu'un utilisateur ne puisse lire que sa propre ligne et que rien ne puisse être écrit depuis le navigateur. »
- Webhook. « Crée une fonction webhook Stripe qui vérifie l'en-tête Stripe-Signature avec le secret du webhook, puis traite checkout.session.completed, invoice.paid, invoice.payment_failed, customer.subscription.updated et customer.subscription.deleted en mettant à jour la table subscriptions. Elle doit pouvoir recevoir deux fois le même événement sans risque, et ne doit pas exiger de connexion utilisateur. »
- Accès. « Lis la table subscriptions pour décider de ce qu'un utilisateur peut utiliser. Affiche un état verrouillé avec un bouton de mise à niveau sur [fonctionnalité] pour les utilisateurs dont le statut n'est ni active ni trialing. Ne fais jamais confiance à la page de succès pour débloquer quoi que ce soit. »
- Portail. « Ajoute dans les paramètres un bouton Gérer la facturation qui appelle une fonction serveur créant une session de portail client Stripe pour l'utilisateur actuel et renvoie son URL. »
- Échecs. « Quand un paiement échoue, affiche un bandeau demandant à l'utilisateur de mettre à jour sa carte, avec un lien vers le portail. »
Le premier message est le plus important ; notre guide pour écrire les bons prompts pour construire une app explique pourquoi.
Comment Cadrant s'y prend
Cadrant, notre créateur d'app, génère des applications web React avec un backend Supabase, et gère Stripe par des edge functions Supabase dans votre propre projet Supabase. Vous demandez l'intégration dans le chat, par exemple « Ajoute le paiement Stripe pour des abonnements ». Cadrant écrit le code de l'edge function et la déploie dans votre projet Supabase. D'après notre documentation sur les edge functions, le navigateur appelle la fonction par l'API Supabase et les clés ne l'atteignent jamais.
Vous ajoutez la clé vous-même dans le panneau Environment du projet, sous le panneau Database, sous la forme d'une variable comme STRIPE_SECRET_KEY, et le secret du webhook comme seconde variable. Selon la page sur les variables d'environnement, les variables ne sont disponibles que pour le code serveur et peuvent être modifiées sans redéployer l'app. Ne collez jamais une clé secrète dans le chat. L'IA écrit aussi les migrations de base de données avec la row level security, donc la table subscriptions de l'étape 2 suit les mêmes règles que le reste de vos données.
Cadrant n'est pas la seule façon de faire. Tout créateur qui génère des fonctions serveur peut suivre les mêmes étapes, et si vous voulez un contrôle total de la logique de facturation, faire relire le code généré par un développeur avant le lancement reste une bonne idée. Stripe gère l'argent et les données de carte dans tous les cas ; votre code décide seulement qui obtient l'accès.
Une fois les paiements en place, publiez sur votre propre domaine ; notre guide pour mettre en ligne une application web couvre cette étape.