Webでサブスクを売る案件で、退会の処理をどこに置くかを最初に決めることになりました。
「退会したい場合はお問い合わせください」という文言をよく見ます。サービス提供側から見れば、解約を踏みとどまらせたい気持ちは分かる。でも実際は、問い合わせが来るたびに誰かが手作業で解約処理をやることになって、運用コストがかかりつつ、ユーザーからの心証も悪くなる。一番良くない形です。
だったら最初から、ユーザー自身が退会できる導線を置いたほうがいい。そう決めた上で、どう実装するかを考えました。
自前の退会フォームは作らなかった
最初に考えたのは、退会ボタンを押したらバックエンドがStripeに解約を送る、という自前の実装です。ユーザーが画面上でボタンを押す → 解約処理が走る → スプレッドシートの契約情報が更新される、という流れ。
でも、途中でやめました。
自前で作ると、解約処理の確認ダイアログ、解約後のメッセージ、途中でエラーが起きた時のリカバリ、ユーザーが何度も押した時の多重処理の防止……と、作る量が増えていく。しかも決済まわりの処理は、自前で作ったものに不具合が出た時のダメージが大きい。月次更新の話になると余計に。
Stripeには、契約者が自分でプランを確認したり解約したりできる「カスタマーポータル」という画面が元から用意されています。これをそのまま使う設計に切り替えました。
AIにどう頼んだか
設計を切り替えた後、実装に入りました。AIへの頼み方はこんな感じです。
メールアドレスを入力したら、そのアドレスで契約しているプランを画面に表示させたい。
- 契約中のプランはグレーアウトして、購入できないようにする
- まだ契約していないプランは購入ボタンを表示する
- 解約・プラン変更は、自前の画面を作らずに決済サービスのカスタマーポータルに飛ばす
- 契約情報はスプレッドシートで持つ
解約処理はカスタマーポータル側で完結するので、こっち側のコードでは「カスタマーポータルのURLに飛ばす」だけにしたい。解約Webhookはそのうち追加するとして、今は後でつなげる前提で置いておいて。
「カスタマーポータルに飛ばすだけ」と明示したのが、この件で一番効いた指示です。解約処理を自前で書こうとすると、考慮漏れが出やすい。飛ばすだけにすると、Stripe側が処理してくれるので、こっちが壊せる部分がほぼない。
詰まった所
詰まったのは、実装の途中でした。
Stripeへの接続がうまくいかないエラーが出て、コードをよく見たら、シークレットキーの先頭が spk_ になっていました。正しくは sk_ です。ほぼ同じ文字が並んでいるので目で確認しても見落としていた。動かないエラーの原因が変数のタイポ、というのはよくあります。
もう一つ詰まったのは、Stripe Checkoutの遷移まわりです。iframeの中でStripe Checkoutを呼び出す形にしたら動かなかった。Stripeの仕様で、Checkoutはiframe内では動かせないためです。トップレベルのウィンドウでリダイレクトする形に変えて解決しました。
この2つは、コードの問題というより「仕様上こうしないといけない」という制限にぶつかった形でした。動かなくなったらエラーメッセージをそのままAIに貼って確認する、という手順で片付けていきました。
LINEボット版の場合
別の案件では、LINEのLIFF（LINEの中でWebページを動かす仕組み）上に退会処理を作りました。「退会はこちらから」というボタンをボットの画面に置いて、タップするとLIFF画面に遷移し、退会を実行できる形です。
この場合も、退会処理はStripeのAPIを呼ぶだけにしました。自前で状態管理を複雑にしないこと、退会後の状態をスプレッドシートに反映することの2点を最初に決めておくと、実装の規模が膨らまずに済みます。
LINE IDとStripeの顧客情報をどう紐づけるかは、LINEのID仕様上の制約があって設計に手間がかかる部分です。そこだけ注意が要りますが、「退会ボタンをLINE上に置いてユーザー自身が押す」という仕組み自体はそれほど複雑ではありません。
整理すると
退会の問い合わせが来ないようにするには、退会できる場所をちゃんと作ることです。分かりきった話ですが、「問い合わせ対応で受けよう」という設計が残ったまま運用を始めると、後から直すのが面倒になります。
自前で退会フォームを作り込まなくても、決済サービスが用意している管理画面をそのまま使う設計にすれば、作る量も壊せる部分も少ない。最初から手を抜ける部分は手を抜いておくほうが、結果的に安定します。
「退会したいのですがどうすればいいですか」という問い合わせを受ける導線を最初から作らない。そう決めておくだけで、後から運用に追われずに済みます。