Skip to main content

Créer un flux Stripe Checkout

Confiez à Devin une spécification de flux de paiement avec vos clés sandbox Stripe et obtenez un flux de paiement fonctionnel — page de tarification, session de paiement, gestionnaire de webhook et page de confirmation — vérifié dans le navigateur.
AuthorCognition
CategoryDéveloppement de fonctionnalités
1

(Facultatif) Définir la portée de la base de code avec Ask Devin

Si vous ne savez pas comment votre application gère les paiements à l’heure actuelle — ni à quels fichiers et patterns vous référer dans votre spécification — utilisez Ask Devin pour commencer votre investigation :Utilisez les réponses pour compléter votre spécification — faites référence à des fichiers, noms de tables et patterns précis afin que Devin construise quelque chose qui s’intègre naturellement à votre base de code. Vous pouvez aussi démarrer une session Devin directement depuis Ask Devin, et celle-ci conservera tout ce qu’il a appris comme contexte.
2

Ajouter les clés de test Stripe

Devin a besoin de clés Stripe en mode test pour créer des sessions de paiement et vérifier le gestionnaire de webhook. Utilisez toujours des identifiants d’environnement de test (sandbox) — ne donnez jamais à Devin de clés Stripe de production.La façon la plus simple de procéder est de les stocker en tant que secrets d’organisation avant de démarrer la session :
  1. Allez dans Settings > Secrets et ajoutez :
  2. Devin y accède sous forme de variables d’environnement, de sorte qu’elles ne se retrouvent jamais en dur dans votre code source.
Les secrets d’organisation doivent être ajoutés avant de démarrer la session — ils sont injectés au démarrage de la session. Vous pouvez aussi fournir des secrets pendant la session via le chat, et Devin vous demandera de manière proactive tous les identifiants dont il a besoin lorsqu’il rencontre des variables d’environnement manquantes.
3

Transmettez les spécifications de votre checkout

Collez votre spécification — à partir d’un PRD, d’un ticket Linear ou d’un message Slack détaillé — directement dans Devin. Une bonne spécification de checkout couvre les paliers tarifaires, le flux de paiement et ce qui se passe après un paiement réussi. Plus c’est structuré, mieux c’est.Une bonne spécification pour Devin inclut trois éléments : quoi construire (paliers tarifaires, flux de paiement, gestionnaire de webhook), où il se trouve (routes, tables, fichiers) et comment cela s’intègre (patterns existants à suivre). Vous n’avez pas besoin de spécifier chaque détail d’implémentation — Devin examine votre base de code pour combler les lacunes.
4

Devin construit et vérifie dans le navigateur

Devin lit votre spec, explore la base de code pour trouver des modèles similaires, puis met en œuvre les changements sur toute la stack. Avant d’ouvrir une PR, il exécute votre application en local et ouvre son navigateur intégré pour vérifier que le flux de paiement fonctionne de bout en bout.Voici à quoi cela ressemble pour l’exemple de checkout Stripe :
  1. Crée la migration — Ajoute la table subscriptions avec des colonnes pour user_id, stripe_subscription_id, plan, status et current_period_end
  2. Construit la page de tarification — Crée des cartes de tarification en trois niveaux sur /pricing, chacune avec un bouton « Subscribe » qui envoie une requête à l’API de paiement
  3. Implémente la création de session de checkout — Implémente POST /api/checkout/sessions, qui crée une session Stripe Checkout avec le bon identifiant de prix, l’email du client et les URL de redirection
  4. Ajoute le gestionnaire de webhook — Implémente POST /api/webhooks/stripe avec vérification de la signature, gestion de l’événement checkout.session.completed et mises à jour de la base de données
  5. Construit la page de succès — Crée /checkout/success, qui récupère la session Stripe, affiche le nom du plan, le montant facturé et un lien « Go to Dashboard »
  6. Écrit les tests — Ajoute des tests pour la vérification de la signature du webhook (valide, invalide, manquante), la création de session de checkout et la logique de mise à jour du plan dans la base de données
  7. Ouvre le navigateur — Démarre le serveur de développement, navigue vers /pricing, clique sur « Subscribe » pour l’offre Pro, vérifie que la redirection Stripe Checkout fonctionne et que la page de succès s’affiche correctement après un paiement de test
  8. Ouvre une PR — Propose l’ensemble des changements avec un récapitulatif de ce qui a été implémenté et de la façon dont cela a été vérifié
L’étape de vérification dans le navigateur permet de détecter des problèmes que les tests unitaires ne couvrent pas — une carte de tarification qui ne déclenche pas le paiement, une URL de redirection qui renvoie une 404, ou une page de succès qui ne parvient pas à charger les détails de la session. Si vous avez défini un skill de test local, Devin suit ces étapes automatiquement pour chaque fonctionnalité qu’il construit.
5

Itérer depuis la PR

Une fois la pull request (PR) ouverte, envoyez des prompts de suivi dans la même session pour étendre ou ajuster le parcours de paiement.
6

Passez en revue la PR avec Devin Review

Une fois que Devin a ouvert la PR, utilisez Devin Review pour examiner les modifications. Devin Review dispose du contexte complet de votre base de code et peut détecter des bugs, des problèmes de sécurité et des incohérences de style sur l’ensemble du diff. Vous pouvez poser des questions complémentaires dans le chat de revue — par exemple : « Le gestionnaire de webhook valide-t-il le type d’événement avant de le traiter ? » — et Devin répondra en s’appuyant sur le code réel.