Stripeが新しくリリースした料金表の実用性

料金表とは

Stripe では現在プランの表示、登録が可能な料金表と、顧客が自身の支払い管理をするためのカスタマーポータルをノーコードでサイトに埋め込めるようになっています。

このような料金表がノーコードで埋め込める

これにより以下の手順ですぐにサブスク型のスモールビジネスを開始できます。

1. 商品や値段を作成
2. 料金表を作成
3. 顧客にカスタマーポータルの URLを提供

料金表には一般的な UI（機能）をノーコードで有効にできます。

• 人気のプラン
• 年額によるお得さの演出
• プランごとの特徴リスト（A プランと B プランでそれぞれできることの羅列）
• 無料トライアル

Stripe とサービスの DB で商品データを同期させつつ上記の UI を自分で実装するのは結構大変です。また Stripe 上の価格と UI の価格の間に一時的に差分が生じ、顧客に混乱を生む恐れもあります。

料金表は色、角丸、フォントぐらいはカスタマイズできるのである程度サイトの雰囲気に寄せることもできます。今後スモールスタートしたい個人プロダクトやオンラインサービスではかなり有用な選択になると思います。

現状の課題

とはいえ現状は以下の課題があり、まだ実用的とはいえません。

• ゲストユーザーを弾くことができない
• プラン登録ごとに Stripe 上に新規顧客が作られる
• 現状のステータスを判断できない

以下詳細です。

ゲストユーザーを弾くことができない

ゲストユーザーを弾くことができないので、非ログインユーザーが閲覧するページの料金セクションに掲載することができません。正確にはできますが、後述する通りかなりアナログな運用になります。

決済は一般的にフルフィルメントと呼ばれる決済後の処理が付随します。課金したユーザーを自動的に Discord に招待&ロールを付与したり、有料メンバーの権限を付与する、などが決済後処理の代表例です。

フルフィルメントを行うにはどのユーザーが登録したのか？ を知る必要があります。料金表は client-reference-id というプロパティでその情報を受け取ることができますが、それが空の場合でも登録できてしまいます。空の場合ログインページに飛ばすといったオプションもないので、ゲストユーザーが LP から登録してしまった場合得体の知れない誰かが課金した状態となり、フルフィルメントができません。

Stripe ダッシュボードから新規顧客を目視でチェックし、手動で権限付与等を行う必要があります。また Stripe の顧客とプロダクトのユーザーが関連付いてないので解約時や決済がコケた際も同様に手作業で権限削除などを行う必要があります。

プラン登録ごとに新規ユーザーが作られる

料金表にサービスのユーザー ID や Stripe の顧客 ID を渡したとしても内部的に登録状態が紐づけられることはありません。したがって料金表経由で登録する場合、毎回新規顧客が作られます。最悪なケースとしてはユーザーが気づかずに何度もプラン登録ステップを踏んだ場合、そのステップの数だけ Stripe 上に顧客が作られ、課金が重複して開始されます。

client-reference-id でユーザー ID を渡せる場合、フルフィルメントの過程でアプリ側で重複登録を判定できるのでただちに Stripe API 経由で課金をキャンセルする対応は可能ですが、おそらくユーザーには課金スタートメールが重複して飛ぶこととなり精神衛生上（およびリスク的に）よろしくないです。

現状のステータスを判断できない

前述の課題は料金表が顧客 ID を解釈しないことが根本的な原因になっています。client-reference-idに Stripe の顧客 ID を渡しても単なる文字列としてフルフィルメント時に返却されるだけです。

そのため、既に課金中のユーザーが料金表を表示した際に以下のような対応ができません。

• 加入中のプランにラベルをつけたり登録ボタンを非活性にする（あるいは解約ボタンにする）
• 前後のプランのボタンラベルをダウングレード、アップグレードといった相対的な表記にする

したがって前述したように、毎回新規顧客として新たな課金がはじまってしまいます。プラン変更、解約に関してはそもそもカスタマーポータルの領域なので加入中のユーザーはアプリの UI レベルで表示を切り替え、カスタマーポータルへのリンクを表示することで一応対応は可能ですが、その場合最初に述べたように LP や料金ページに情報として掲載することはできません。

どのようなシーンで使えるのか

前述の課題は Stripe Developers Discord で話題になっており、Stripe チームも課題として認識しているようなのでそのうち解決すると思います^[1]。

以下のシーンでは料金表を使っても良いと思います。

顧客が極端に少ない

そもそも想定するユーザーが極めて少ない少人数制のオンラインレッスンなどではアナログ管理でも十分対応が追いつくので料金表を LP において、ダッシュボード経由で顧客管理ができると思います。（そもそも極端に少ない場合毎月銀行振込してもらうことで Stripe 手数料を回避できますが）

万が一ユーザーが重複登録してしまった場合ダッシュボードからポチッと返金できます。

フルフィルメントが必要ない場合

この場合 LP に野ざらしにしても問題ありませんが登録後必要な対応がすべて手作業である点に注意してください。

ログイン中のユーザーにのみ料金表を表示する

この場合フルフィルメントを確実に行えます。が、重複課金の課題は未解決なのでフルフィルメントかマニュアル運転で弾く必要があります。

未来予想

すでに SNS で集客チャネルがある方が上記のようなサイトビルダーを使って料金表とカスタマーポータル URL を埋め込んだ LP を作ってサクッとサブスクビジネスをはじめるケースがわりと増えると思います。Menta やサロンプラットフォームは手数料が痛いので自分で集客できる人にとっては Stripe や PayPal が有力な選択肢になると思います。

料金表の課題が解決すれば Zapier などと連携して「登録後 Discord でロール自動付与」などの運用自動化も可能になると思います。

参考

料金表を使わない場合 Payment Links という選択肢もありますが、同様にフルフィルメントには難があるようです。

Payment Links を利用した場合、同じメールアドレスでも、申し込みの度に新しい Customer データが Stripe に作成されます。

https://qiita.com/hideokamoto/items/ad672c3d7141c6e1430a?utm_campaign=post_article&utm_medium=twitter&utm_source=twitter_share

脚注

1. 顧客 ID を iframen に渡すのはセキュリティ的に無理というアンサーもあるのでどのような対応になるかは未知数