この記事は、JP_Stripes Advent Calendar 2020の初日記事です。

Stripe Billingを利用する場合どうしても以下のような実装を自前で行う必要がありました。

• 支払い方法の登録・削除
• Subscriptionのプラン変更・解約
• 支払い履歴の表示やレシートのDL

これまではStripe APIを使ってAPIを作成し、React / AngularなどでViewを作るという作業を繰り返していました。

しかし、Stripeの「カスタマーポータル」を利用することで、この手間がなくせるかもしれません。

有効化する

デフォルトではオフになっていますので、設定画面からオンにしましょう。 test / liveそれぞれで操作してやる必要がありますので、live側の操作もお忘れなく。

デザインの調整は「ブランディング」から

ブランディングからある程度表示を変更できます。メールやCheckoutと似た感じですね。

ユーザーの操作できる機能を制限

設定画面からどの操作を許可するかが選べます。

「請求書を閲覧・DLだけさせたい」「支払い方法の変更だけさせたい」「プラン変更や解約も」のように細かいニーズにあわせて設定できるのはありがたいところです。

利用規約・プライバシーポリシーと遷移先をしていする

Billingを本番利用する際にも指摘されることがありますが、利用規約やプライバシーポリシーページは必須です。ホスティング側で用意し、リンクを貼りましょう。

リダイレクトリンクを入れておくと、ポータルを抜ける時に戻るページを指定できます。

選べる商品も指定可能

ユーザーがプラン変更などをできるようにする場合、選べる商品を指定することができます。

ホワイトリスト形式の様子ですので、選べるようにする場合は必ず追加してやりましょう。

カスタマーポータルのURLを発行する

セットアップが終われば、早速ポータルのURLを作りましょう。

URL作成にはStripe Customer IDが必要

このカスタマーポータル、作成APIがbilling_portal/sessionであることからもわかるように期限つきのURLです。

curl https://api.stripe.com/v1/billing_portal/sessions \
  -u sk_test_xxxxxxxx: \
  -d customer=cus_xxxxxx

ちなみにNode.jsなどではSDKを利用して作成できます。

const stripe = require('stripe')('sk_test_xxxxxxxx');
 const session = await stripe.billingPortal.sessions.create({
   customer: 'cus_Ixxxxxx',
   return_url: 'https://example.com/account',
 });

有効期限が切れるとこのような表示になるので要注意です。

StripeのSecret Keyを利用する関係上、Serverless FrameworkなどでAPI化して実行するのが無難です。その場合、StripeのCustomer IDもAuth0 / Cognito / Firebaseなどのmetadataから取るようにして、リクエスト内に含めないようにするとより安全になるかと思います。

が、どうしてもという場合は、「制限つきのAPIキー」を作成し、カスタマーポータルへのURL発行以外の操作をDenyしてしまうという方法もあるにはありそうです。お勧めはしません。

アプリ側でユーザーとStripe Customer IDを紐付けする

Cognito User PoolsやAuth0, FirebaseまたはWordPressなど、多くのユーザー管理ができるサービス・アプリでは、ユーザーのデータにmetadataが設定できます。

少し手間になりますが、初回の契約時・アカウント作成時などに、StripeのAPIから返されたcustomer idをmetadataへ保存してやりましょう。

イメージとしてはこのようなものですね。

const { id } = await stripe.customers.create(...)
await auth0Client.updateAppMetadata({ id: 'USERNAME'}, {
  stripeCustomerId: id
})

Stripe側のmetadataにAuth0などのユーザー名をいれてやると、あとで突き合わせが楽になるかもしれません。

「手早くSaaSを作りたい」ならカスタマーポータルをつかおう

最後にやはりコードを書く必要がでてきました。が、このカスタマーポータルでできることを自前で実装する手間を考えると相当な工数削減です。

案件の内容や規模感にもよりますが、「個人的にリリースするSaaS」や「収益化できるかわからないので、コストをあまりかけたくない案件」などでは自前で実装する工数をカスタマーポータルでガッツリ削っちゃいましょう。

Appendix1: 実装方法を変更する必要があるケース

Stripe上で操作を行うため、例えば以下のようなケースはStripeのWebhook経由で実行する必要があります。

• プラン変更後、Dashboardのアクセス可能ページを変更する（WebSocketやポーリングが必要かも）
• 変更されたプランのデータを顧客DBなどに保存する
• Google Analyticsなどでコンバージョンまたはイベントをトラッキングする

簡単に操作させれるが、操作結果をWebhook以外から受け取れなくなると考えると良いかなと思います。

「サービスの設定変更に失敗したらロールバックする」などの操作を行う場合は、自前でUIを用意してメッセージングしてあげた方がトラブルが起きにくいかもしれません。

Appendix2:自前で実装する必要があるケース

Stripe Checkout同様、シンプルなユースケースに使えるように作られています。

そのため、以下のようなケースでは、これまで通りに実装する必要がありそうです。

• それぞれのUIを独自に実装したい場合
• プラン変更前に実行すべき処理があるケース
• ユーザーごとに操作権限が異なるケース