Stripeの管理画面を開いたら、同じメールアドレスの顧客がいくつも並んでいた。
個人ジム向けのサブスク課金システムを組んでいたときの話です。会員がプランを選んで決済画面に進むたびに、顧客IDが新しく発行されていました。本人は購入を完了していないのに、です。Stripeのダッシュボードには、名前も同じ、メールも同じ、でも別IDの顧客が並んでいく。これが続くと、どの顧客IDに契約を紐づけるか判断できなくなります。
購入画面を開いただけで増える問題
最初にAIに投げた相談はそのままです。
このコードだが、購入手続きをしていないのにstripeに顧客IDが作成されてしまう
原因はバックエンドの処理の順番にありました。サブスクリプション状態を確認するときに、ついでに「顧客IDを取得する、なければ作る」という処理が走っていた。ユーザーがページを開いただけで、確認処理が動いて、顧客IDが生まれていた。
ここを直してもらいました。確認処理では既存のIDを調べるだけにして、IDがないからといって新しく作らない。顧客IDの作成は「購入を完了したとき」だけに絞る、という整理です。
二段階で詰まった話
ただ、一回直して終わりじゃなかった。
状態確認のタイミングは直せた。でも次に気づいたのがこれです。
stripeで購入画面を出しただけで、顧客IDが作成されてしまう
Stripeの決済ページを表示するとき、バックエンドでチェックアウトセッションを作ります。このセッション作成のときにも「まず顧客IDを取得または作成してから渡す」という処理が入っていた。だから、ユーザーが「購入する」ボタンを押してページに進んだだけで、IDが増えていた。
さらにその次に気づいたのが、もう一層の問題です。
この仕組みだとStripeの内で顧客IDに様々な契約が紐づかないからダメなんだった。契約ごとに顧客IDが作られてしまう
そうなんです。Stripeは本来、一人の顧客に複数のサブスクリプションを紐づける設計になっています。でも新規作成を繰り返していると、同じ人でも契約ごとに別のIDができてしまう。プラン変更や二つ目の契約のとき、管理がぐちゃぐちゃになります。
問題が3層あった、という感じです。
AIへの頼み方
ここからは、AIに修正を依頼した話です。コードは貼りません。「こういう考え方で頼んだ」という部分だけ書きます。
まず整理した設計方針はこれです。
チェックアウトセッションを作るとき、事前に顧客IDを発行しないようにしたい。新規ユーザーなら、メールアドレスだけ渡してStripeに任せる。購入が完了したら、Webhookで顧客IDを受け取って、そのときに初めてシステムに記録する。
既存ユーザーの場合は別で、メールアドレスで突合して、すでに顧客IDが登録済みならそれを使う。同じIDに複数の契約を紐づけるため。
ポイントは「IDの作成タイミングを後ろにずらす」ことです。購入画面を開くタイミングではなく、実際に決済が完了したタイミングで初めて記録する。それまでは顧客IDを発行しない。
新規と既存で処理を分けるところが少し手間で、デプロイしたらコードの構文エラーが出て一度詰まりました。AIに見直してもらって修正、という往復が数回ありましたが、最終的には動く形まで持っていけました。
メール突合という考え方
この仕組みで核になるのは「メールアドレスで同一人物かどうか判定する」という設計です。
Stripeに登録済みの顧客のメールアドレスと、今ログインしているユーザーのメールアドレスを照合する。一致したら既存の顧客IDを再利用する。一致しなければ、Stripe側に任せて購入完了後に新規IDを受け取る。
シンプルです。ただこれをやるには、顧客IDをどこかに保管しておく必要があります。スプレッドシートでも、データベースでも。「このメールアドレスの人は、Stripeでこの顧客IDです」という対応表が手元にないと、突合できません。
逆に言えば、この対応表さえ作っておけば、あとはチェックアウト時に照合するだけです。
気をつけたいこと
一点だけ。
この設計では「購入を完了するまでStripeに顧客IDが存在しない」という状態になります。管理画面上は、決済が終わるまで顧客が現れない。これは正しい動作ですが、確認のときに「あれ、登録されていない？」と思うことがあります。慌てて手動で作る必要はありません。Webhookが動いて、購入完了のタイミングで自動的に記録されます。
Webhook（外部からの通知を受け取る仕組み）が正しく動いているかは、最初に必ずテスト購入で確認しておいてください。ここが動いていないと、購入完了後も管理表に記録されない、という問題が起きます。
サブスク課金を自分で組むと、決済まわりは意外と詰まる箇所が多いです。Stripeの仕様を読んでもピンとこないまま進めて、管理画面がカオスになってから気づく、というパターンをよく見ます。設計段階で「どこで顧客IDを作るか」を決めておくと、後から直す手間がだいぶ減ります。