概要
軽い気持ちで運用も考えずにサブスク導入（自作）を行い大失敗している（現在進行形）私の懺悔をここに記します。
皆さん、どうか・・・どうかサブスク導入（自作）を軽く考えないでください。
私について
所謂キャリアチェンジ組。
フロントエンドエンジニア 4年、Next.js、Typescriptの開発がメイン。
Backend経験ほぼ無し。インフラも軽ーく触った程度。
事の発端
社内でマネタイズのために自社アプリにサブスクシステムを追加すべくStripeの導入を検討。
他に対応できる社員がおらず私に白羽の矢が立つ。
Stripe導入は前の会社で一度簡単に実装した程度。
いったん最低限の機能であるサブスク購入と購入後のロジックが動く＋顧客がポータル確認できれば良いということで実装依頼を受ける。（要件定義はほぼ無いに等しいです）
ロジックは以下の２つのみ
- 支払い成功イベントに応じて機能付与
- 支払い失敗に応じて機能剥奪
- 顧客は管理画面（カスタマーポータル）から自分の支払いがみれる
- 単体のサブスクではなく、ユーザーは複数のサブスクが購入できる
君を地獄に陥れる３つの罠
とにかく時間もなく登録された商品購入が出来たという事実だけ確認し
本当に最低限の機能のみをつけログや通知周りなどは未実装の状態でリリース（罠１）
リリース時点で商品の登録、更新など
どの部署がサブスク運用するかが決っていない（罠２）
当然ながら顧客の支払い失敗や決済リトライなど
どういうユースケースがあるのか誰も把握していない（罠３）
こうして地獄のサブスク運用が始まりました・・・。
地獄の始まり
初めはアプリの運用チームの問い合わせからでした。
「サブスク登録されているAさんに本来つくはずの機能がついていません、確認お願いします。」
確認するとユーザー側で支払いが失敗したが、その後、ユーザーが再度別カードで購入し成功。
しかし、元カードの失敗リトライが継続しており成功後に
失敗イベント通知 → 機能剥奪発火
となっていた。
「何やってんの？謝るのこっちなんだけど？」
「すいません・・・」
今度は別の問い合わせで
「サブスク登録してないのに機能ついてんだけど？」
ログも無いので原因分からず。
「どうなってんの？機能して無いじゃん」
「ぴえん・・・」
またまた別の問い合わせで
「お客さん・・・二重に支払ってるんだけどしかも３ヶ月間」
調べてみると支払い失敗後に別のサブスクとして同じ商品を新規登録し、
その後失敗したサブスク処理のリトライが成功し結果同じ商品に対して二重の支払いが発生。
「お客さんの信頼失ってるんですよ？理解してます？」
「・・・」
なんとか改善、だが起死回生とはならず
今回の件を踏まえて以下の改善を実施
- 決済リトライの停止（支払い失敗時は即キャンセル扱い）
- ログの強化
- 支払い失敗時の通知設定、即検知
- Webhook全量確認、どのイベントが必要でイベントで何を発火させるのかを整理
そしていざリリース。
これで問題はある程度解決したか・・・？
そんなことはなく、即座に別の問題が発生。
さらに続く地獄
サブスク購入ページへつながるリンクはボタンではなくURLをページにベタ貼りする運用になっており、ユーザーが新規顧客の場合で複数回クリックをすると複数同じ顧客ができる事態に。これにより支払い済み顧客の機能剥奪が発生。
「・・・いやそれくらい制御せいよ、マジで」
「・・・」
この時点で一人で不具合調査、修復、他部署との連携諸々を行っており既に限界。
半分お手上げの状態で開発チーム全体にアラーム。外注なども視野に入れ解決策を模索中。
結論
お金の話だから本当にちゃんと保守・運用を含めてしっかり考えて欲しいと思い記事を書きました。
まだ地獄真っ最中なので書き殴りご勘弁ください。
Stripeなど自社で作れるサブスクツールはドキュメントも充実しており本当に手軽に実装・導入できるようになってます。
しかしながら、それは同時に自分のような半端者でも導入ができてしまうということでもあります。
今回の件を踏まえ自分も反省し現在できる限りの手を尽くして改善を行っていますが、導入できるというだけでStripeなど金銭に関わるシステムを半端な気持ちで容易に導入する際はやめていただき、特に運用・保守、あらゆるユースケースをしっかりと考えた上で自作にするかどうかの判断をしてください。
外注はお金はかかりますがその分自社の信頼は保てます。
自作は下手すると本当に大きく信頼を失います。下手すると会社全体が大きなダメージを被ります。
色々間違うと上記のようなリスクがあるということを理解した上で自作という手段をとっていただきたいと切に願い書き留めさせていただきます。