Non vuoi configurare tutto manualmente? Incolla un collegamento a questa pagina in una sessione di Devin e chiedigli di impostare tutto per te. Se non sei sicuro di come la tua app gestisca attualmente i pagamenti — o quali file e pattern usare come riferimento nella tua specifica — usa [Ask Devin](https://app.devin.ai/search?utm_source=docs\&utm_medium=use-case-gallery) per eseguire prima un'analisi: ```txt Scope the checkout implementation theme={null} How does our app currently handle billing? Show me: 1. Where user plans/subscriptions are stored in the database 2. Any existing Stripe integration files or API routes 3. How other payment-related pages are structured (e.g., settings/billing) 4. What ORM we use and how migrations are typically created ``` Usa le risposte per completare la tua specifica — fai riferimento a file specifici, nomi di tabelle e pattern, affinché Devin crei qualcosa che si integri in modo naturale nella tua codebase. Puoi anche avviare una sessione di Devin direttamente da Ask Devin, e userà tutto ciò che ha appreso come contesto. Devin ha bisogno delle chiavi Stripe in **modalità test** per creare le sessioni di checkout e verificare l'handler del webhook. Usa sempre le credenziali sandbox — non fornire mai a Devin le chiavi Stripe di produzione. L'approccio più semplice è memorizzarle come [organization secrets](/it/product-guides/secrets) prima di avviare la sessione: 1. Vai su **Settings > Secrets** e aggiungi: * `STRIPE_SECRET_KEY` — la tua chiave segreta in modalità test dal [Stripe Dashboard](https://dashboard.stripe.com/test/apikeys) * `STRIPE_WEBHOOK_SECRET` — il segreto di firma dalle [impostazioni dell'endpoint webhook](https://dashboard.stripe.com/test/webhooks) 2. Devin accede a queste chiavi come variabili d'ambiente, così non finiscono mai inserite in modo statico nel tuo codice sorgente. Gli organization secrets devono essere aggiunti **prima** di avviare la sessione — vengono iniettati all'avvio della sessione. In alternativa, puoi fornire i secrets durante la sessione tramite la chat, e Devin ti chiederà anche in modo proattivo tutte le credenziali necessarie quando rileva variabili d'ambiente mancanti. Incolla la tua specifica — da un PRD, un ticket Linear o un messaggio dettagliato su Slack — direttamente in Devin. Una buona specifica per il checkout copre i piani tariffari, il flusso di pagamento e cosa succede dopo un pagamento riuscito. Più è strutturata, meglio è. ```txt Implement Stripe checkout flow theme={null} Implement a Stripe checkout flow for our SaaS app: ## Pricing page - New route at /pricing with three tier cards: - Starter: $19/mo — 5 projects, 10GB storage, email support - Pro: $49/mo — unlimited projects, 100GB storage, priority support - Team: $99/mo — everything in Pro + team management, SSO, audit log - Each card has a "Subscribe" button that initiates checkout ## Checkout - POST /api/checkout/sessions — crea una sessione Stripe Checkout con il price ID selezionato, l'email del cliente e gli URL di successo/annullamento - Reindirizza l'utente alla pagina di checkout ospitata da Stripe - In caso di successo, reindirizza a /checkout/success?session_id={CHECKOUT_SESSION_ID} ## Webhook - POST /api/webhooks/stripe — receives Stripe events - Handle checkout.session.completed: update the user's plan and subscription_id in the database - Verify the webhook signature using STRIPE_WEBHOOK_SECRET ## Success page - /checkout/success — recupera i dettagli della sessione da Stripe, mostra il nome del piano, l'importo e un pulsante "Go to Dashboard" ## Planning - Before writing any code, outline your implementation plan and share it with me for approval. List the files you'll create or modify, the database changes, and the order of implementation. ## Technical notes - Follow the patterns in src/pages/settings/billing.tsx for the UI - Use Prisma: add a subscriptions table (id, user_id, stripe_subscription_id, plan, status, current_period_end) - STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET are available as env vars ## Testing & verification - Write tests for webhook signature verification, session creation, and the plan-update logic - After implementing, spin up the local dev server and verify the entire flow in the browser: navigate to /pricing, click Subscribe, complete a test payment with Stripe's test card (4242 4242 4242 4242), confirm the success page renders, and verify the database was updated - Do not open a PR until you've confirmed everything works end-to-end ``` A good spec for Devin includes three things: **what** to build (pricing tiers, checkout flow, webhook handler), **where** it lives (routes, tables, files), and **how** it fits in (existing patterns to follow). You don't need to specify every implementation detail — Devin investigates your codebase to fill in the gaps. Devin reads your spec, explores the codebase for matching patterns, then implements across the full stack. Before opening a PR, it runs your app locally and opens its [built-in browser](/it/work-with-devin/devin-session-tools) to verify the checkout flow works end-to-end. Here's what that looks like for the Stripe checkout example: 1. **Creates the migration** — Adds the `subscriptions` table with columns for `user_id`, `stripe_subscription_id`, `plan`, `status`, and `current_period_end` 2. **Builds the pricing page** — Creates the three-tier pricing cards at `/pricing`, each with a "Subscribe" button that posts to the checkout API 3. **Implements checkout session creation** — Builds `POST /api/checkout/sessions` that creates a Stripe Checkout session with the correct price ID, customer email, and redirect URLs 4. **Adds the webhook handler** — Implements `POST /api/webhooks/stripe` with signature verification, `checkout.session.completed` event handling, and database updates 5. **Builds the success page** — Creates `/checkout/success` that fetches the Stripe session, displays the plan name, amount charged, and a "Go to Dashboard" link 6. **Writes tests** — Tests for webhook signature verification (valid, invalid, missing), checkout session creation, and the plan-update database logic 7. **Opens the browser** — Starts the dev server, navigates to `/pricing`, clicks "Subscribe" on the Pro tier, verifies the Stripe Checkout redirect works, and checks that the success page renders correctly after a test payment 8. **Opens a PR** — Delivers all changes with a summary of what was implemented and how it was verified The browser verification step catches issues that unit tests miss — a pricing card that doesn't trigger checkout, a redirect URL that 404s, or a success page that fails to load session details. Se hai definito una [skill di test locale](/it/product-guides/skills), Devin segue automaticamente quei passaggi per ogni funzionalità che realizza. Una volta aperta la PR, invia prompt di follow-up nella stessa sessione per estendere o modificare il flusso di checkout. ```txt Add subscription management theme={null} Aggiungi una sezione "Manage Subscription" a /settings/billing che mostri il piano attuale, la prossima data di fatturazione e un pulsante "Cancel Subscription". Usa il portale clienti di Stripe per la cancellazione — crea una sessione del portale e reindirizza l'utente. ``` ```txt Add annual pricing toggle theme={null} Aggiungi un selettore mensile/annuale nella pagina dei prezzi. I piani annuali hanno uno sconto del 20%. Mostra il prezzo mensile con una nota "billed annually" e un badge "Save 20%" su ogni scheda quando è selezionata l'opzione annuale. ``` Once Devin opens the PR, use [Devin Review](https://app.devin.ai/review?utm_source=docs\&utm_medium=use-case-gallery) to review the changes. Devin Review has full context of your codebase and can catch bugs, security issues, and style inconsistencies across the diff. You can ask follow-up questions in the review chat — for instance, "Does the webhook handler validate the event type before processing?" — and Devin will answer grounded in the actual code.

{title}