不想手动配置？将本页链接粘贴到 Devin 会话中，让它为你完成所有设置。如果你不确定你的应用目前是如何处理支付的，或者不清楚在规格文档中应该参考哪些文件和模式，可以先使用 [Ask Devin](https://app.devin.ai/search?utm_source=docs\&utm_medium=use-case-gallery) 进行分析： ```txt Scope the checkout implementation theme={null} 我们的应用目前是如何处理计费的？请帮我展示： 1. 用户套餐/订阅在数据库中的存储位置 2. 任何现有的 Stripe 集成文件或 API 路由 3. 其他与支付相关页面的结构（例如 settings/billing） 4. 我们使用的 ORM，以及通常如何创建迁移 ``` 使用这些答案来完善你的规格文档——引用具体的文件、数据表名称和模式，这样 Devin 就能构建出能够自然融入你代码库的功能。你也可以直接在 Ask Devin 中启动 Devin 会话，它会将已经获取的所有信息作为上下文保留下来。 Devin 需要 Stripe 的 **test-mode** 密钥来创建结账会话并验证 webhook 处理程序。请始终使用沙箱凭据——切勿将生产环境的 Stripe 密钥提供给 Devin。最简单的方法是在开始会话之前，将其存储为[组织密钥](/zh/product-guides/secrets)： 1. 前往 **Settings > Secrets** 并添加： * `STRIPE_SECRET_KEY` — 你的测试模式 secret key (密钥) ，可在 [Stripe Dashboard](https://dashboard.stripe.com/test/apikeys) 中获取 * `STRIPE_WEBHOOK_SECRET` — 你的 [webhook endpoint settings](https://dashboard.stripe.com/test/webhooks) 中的 signing secret (签名密钥) 2. Devin 以环境变量的形式访问这些值，因此它们永远不会被硬编码到你的源代码中。组织密钥必须在开始会话**之前**添加——它们会在会话启动时注入到环境中。或者，你也可以在会话期间通过聊天提供密钥；当 Devin 发现缺少环境变量时，也会主动向你请求所需的凭据。将你的规格说明——无论是来自 PRD、Linear 工单，还是一条详细的 Slack 消息——直接粘贴到 Devin 中。一个好的结账规格应涵盖定价档位、支付流程，以及成功支付后的处理逻辑。结构越清晰越好。 ```txt Implement Stripe checkout flow theme={null} 为我们的 SaaS 应用实现 Stripe 结账流程： ## Pricing page - 在 /pricing 新增路由，包含三个定价卡片： - Starter：$19/月 — 5 个项目、10GB 存储、邮件支持 - Pro：$49/月 — 项目数量无限制、100GB 存储、优先支持 - Team：$99/月 — 包含 Pro 的所有功能 + 团队管理、SSO（Single Sign-On，单点登录）、审计日志 - 每张卡片都有一个 "Subscribe" 按钮，用于发起结账 ## Checkout - POST /api/checkout/sessions — 使用选定的价格 ID、客户邮箱，以及成功/取消 URL 创建 Stripe Checkout 会话 - 将用户重定向到 Stripe 托管的结账页面 - 成功后重定向到 /checkout/success?session_id={CHECKOUT_SESSION_ID} ## Webhook - POST /api/webhooks/stripe — 接收 Stripe 事件 - 处理 checkout.session.completed：在数据库中更新用户的套餐和 subscription_id - 使用 STRIPE_WEBHOOK_SECRET 校验 webhook 签名 ## Success page - /checkout/success — 从 Stripe 获取会话详情，显示套餐名称、金额，以及一个 "Go to Dashboard" 按钮 ## Planning - 在编写任何代码之前，先列出你的实现计划并分享给我审批。列出你将创建或修改的文件、数据库变更，以及实现顺序。 ## Technical notes - 在 UI 上遵循 src/pages/settings/billing.tsx 中的模式 - 使用 Prisma：新增一个 subscriptions 表（id, user_id, stripe_subscription_id, plan, status, current_period_end） - STRIPE_SECRET_KEY 和 STRIPE_WEBHOOK_SECRET 可作为环境变量使用 ## 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](/zh/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. 如果你定义了[本地测试 skill](/zh/product-guides/skills)，Devin 会在其构建的每个功能上自动执行这些步骤。 Once the PR is open, send follow-up prompts in the same session to extend or adjust the checkout flow. ```txt Add subscription management theme={null} Add a "Manage Subscription" section to /settings/billing that shows the current plan, next billing date, and a "Cancel Subscription" button. Use the Stripe customer portal for cancellation — create a portal session and redirect the user. ``` ```txt Add annual pricing toggle theme={null} Add a monthly/annual toggle on the pricing page. Annual plans get a 20% discount. Show the per-month price with a "billed annually" note and a "Save 20%" badge on each card when annual is selected. ``` 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}