Skip to main content

Stripe Checkout フローを構築する

Stripe のサンドボックスキー付きのチェックアウト仕様を Devin に渡すだけで、料金ページ、チェックアウトセッション、Webhook ハンドラー、確認ページまで含めた動作する決済フローを構築し、ブラウザ上で検証済みの状態にできます。
AuthorCognition
Category機能開発
1

（オプション）Ask Devin でコードベースの範囲を指定する

現在アプリがどのように決済を処理しているか、また仕様でどのファイルやパターンを参照すべきかよく分からない場合は、まず Ask Devin を使って調査してください:回答をもとに仕様を補完し、Devin があなたのコードベースに自然にフィットするものを構築できるよう、特定のファイル名、テーブル名、パターンを必ず明記してください。また、Ask Devin からそのまま Devin セッションを開始でき、そこで得られた内容はすべてコンテキストとして引き継がれます。
2

Stripe のサンドボックスキーを追加する

Devin がチェックアウトセッションを作成し、webhook ハンドラーを検証するには、Stripe の テストモード キーが必要です。必ずサンドボックス用の認証情報のみを使用し、本番用の Stripe キーを Devin に渡さないでください。最も簡単な方法は、セッションを開始する前にそれらを 組織シークレット として保存しておくことです。
  1. Settings > Secrets に移動し、次を追加します:
  2. Devin はこれらを環境変数として参照するため、ソースコード内にハードコードされることはありません。
組織シークレットはセッション開始時に注入されるため、セッションを開始する前に追加しておく必要があります。別の方法として、セッション中にチャットを使ってシークレットを渡すこともできますし、環境変数が不足している場合には、Devin が必要な認証情報を求めてプロアクティブに確認します。
3

チェックアウト仕様を渡す

PRD、Linear のチケット、あるいは詳しい Slack メッセージなどから、仕様をそのまま Devin に貼り付けてください。良いチェックアウト用の仕様書では、料金プラン、決済フロー、決済成功後に何が起きるかをカバーします。構造化されているほど効果的です。Devin にとって良い仕様には 3 つの要素があります: 何を作るか（料金プラン、チェックアウトフロー、Webhook ハンドラ）、どこに置くか（ルート、テーブル、ファイル）、そして既存の仕組みにどう組み込むか（どの既存パターンに従うか）です。すべての実装詳細を指定する必要はありません — Devin がコードベースを調査し、不足分を補います。
4

Devin はブラウザ上でビルドおよび検証を行います

Devin はあなたの仕様を読み、コードベースを探索して一致するパターンを見つけてから、フルスタックにわたって実装します。PR を作成する前に、アプリをローカルで実行し、組み込みブラウザ を開いて、チェックアウトフローがエンドツーエンドで正しく動作することを検証します。Stripe のチェックアウト例では、次のようになります。
  1. マイグレーションを作成 — subscriptions テーブルを追加し、user_id、stripe_subscription_id、plan、status、current_period_end の各カラムを作成します
  2. 料金ページを構築 — /pricing に 3 段階の料金プランカードを作成し、それぞれにチェックアウト API に POST する「Subscribe」ボタンを追加します
  3. チェックアウトセッション作成を実装 — 適切な価格 ID、顧客メールアドレス、リダイレクト URL を用いて Stripe Checkout セッションを作成する POST /api/checkout/sessions を実装します
  4. Webhook ハンドラーを追加 — シグネチャ検証、checkout.session.completed イベント処理、データベース更新を行う POST /api/webhooks/stripe を実装します
  5. 成功ページを構築 — /checkout/success を作成し、Stripe セッションを取得して、プラン名、請求金額、「Go to Dashboard」リンクを表示します
  6. テストを書く — Webhook シグネチャ検証（有効、無効、未設定）、チェックアウトセッション作成、プラン更新のデータベースロジックに対するテストを書きます
  7. ブラウザを起動 — 開発サーバーを起動し、/pricing に移動して Pro プランの「Subscribe」をクリックし、Stripe Checkout へのリダイレクトが正しく行われることと、テスト決済後に成功ページが正しくレンダリングされることを確認します
  8. PR を作成 — 実装内容とその検証方法の要約とともに、すべての変更を提出します
ブラウザでの検証ステップによって、単体テストでは見逃しがちな問題を検出できます。たとえば、チェックアウトをトリガーしない料金カード、404 になるリダイレクト URL、セッション詳細の読み込みに失敗する成功ページなどです。ローカルテストのスキル を定義していれば、Devin は作成するすべての機能に対して、その手順を自動的に実行します。
5

PR からイテレーションする

PR を作成したら、同じセッション内でフォローアップのプロンプトを送り、チェックアウトフローを拡張・調整してください。
6

Devin Review で PR をレビューする

Devin が PR を作成したら、Devin Review を使って変更内容をレビューします。Devin Review はコードベース全体のコンテキストを把握しており、差分全体にわたってバグやセキュリティ上の問題、スタイルの不整合を検出できます。レビュー用チャットで追質問をすることもできます。たとえば「webhook ハンドラーは処理の前にイベントタイプを検証していますか？」のように質問すると、Devin が実際のコードに基づいて回答します。