Skip to main content

Build a Stripe Checkout Flow

Hand Devin a checkout spec with your Stripe sandbox keys and get a working payment flow — pricing page, checkout session, webhook handler, and confirmation page — verified in the browser.
AuthorCognition
CategoryFeature Development
1

(Optional) Scope the codebase with Ask Devin

If you’re not sure how your app handles payments today — or which files and patterns to reference in your spec — use Ask Devin to investigate first:Use the answers to fill in your spec — reference specific files, table names, and patterns so Devin builds something that fits naturally into your codebase. You can also start a Devin session directly from Ask Devin, and it will carry over everything it learned as context.
2

Add Stripe sandbox keys

Devin needs Stripe test-mode keys to create checkout sessions and verify the webhook handler. Always use sandbox credentials — never give Devin production Stripe keys.The simplest approach is to store them as organization secrets before starting the session:
  1. Go to Settings > Secrets and add:
  2. Devin accesses these as environment variables, so they never end up hardcoded in your source code.
Organization secrets must be added before starting the session — they’re injected at session start. Alternatively, you can provide secrets during the session using the chat, and Devin will also proactively ask you for any credentials it needs when it encounters missing environment variables.
3

Hand off your checkout spec

Paste your spec — from a PRD, a Linear ticket, or a detailed Slack message — directly into Devin. A good checkout spec covers the pricing tiers, the payment flow, and what happens after a successful payment. The more structured, the better.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.
4

Devin builds and verifies in the browser

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 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. If you’ve defined a local testing skill, Devin follows those steps automatically for every feature it builds.
5

Iterate from the PR

Once the PR is open, send follow-up prompts in the same session to extend or adjust the checkout flow.
6

Review the PR with Devin Review

Once Devin opens the PR, use Devin Review 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.