こんにちは、INVOYというクラウド請求書プラットフォームの開発を担当している大網（おおあみ）です。
1年以上前の話になるのですが、INVOYで「有料プラン」（Standardプラン）を導入した際にStripeを利用しました。Webサービスに決済機能を導入する上で必要なことを話していきます。
「有料プラン」にするとなにができるの？
本題に入る前に、INVOY「有料プラン」の内容を説明させてください！！
無料でほとんどの機能を無制限に利用できるINVOYですが、「有料プラン」にアップグレードすると何ができるかをお話しできればと思います。
「有料プラン」（Standardプラン）にアップグレードした時に利用できる機能
- 口座連携機能 Moneytreeを利用して金融機関との連携が可能になります。これにより、口座情報を元にINVOY上で入出金管理や消込をより簡単に行うことができます。（※ CSVでの入出金情報の保存、消込は無料でご利用できます。）
- 資金繰り表 「資金繰り表」の作成機能を利用できます。入出金情報を元に資金繰り表への仕訳をすることで、事業のキャッシュフローを可視化し管理することができます。
Stripeを導入した経緯
元々INVOYでは、Stripeとは別の決済プロバイダーを利用して郵送代行のクレジットカード決済を提供していました。そこからサブスクリプションモデルを導入するにあたり、改めて以下の観点で決済プロバイダーの選定を行いました。
| Stripe | 他社決済プロバイダー | 比較 | |
|---|---|---|---|
| 価格 | - 手数料: 3.0%前後 | - 手数料: 3.0%前後 | Stripeの方がやや手数料率が低いが、ほぼ相違なし |
| 決済機能 | - 定期課金、従量課金を柔軟に組み合わせられる - ユーザー向けの履歴画面が用意されている |
- 月額 + 従量課金のようにユーザーごとに異なる金額を請求することができない - ユーザー向けの履歴画面等はない |
Stripeの方が柔軟にカスタマイズ可能 |
| 開発体験 | - 充実したドキュメント - コンソールが充実しており、コンソールでの操作とAPI操作を一対一で見れる |
- 一般的なドキュメントはある - コンソールはない |
上記の観点で整理した結果、管理画面がない場合の工数と課金の仕組みを考えられる幅が広いStripeを採用することになりました。
「有料プラン」の実装
最初にお伝えしたとおり、「有料プラン」にはStripeという決済プロバイダーを利用しています。
「有料プラン」には月額プランと年額プランの2種類の定額サブスクリプションがあり、その前段には1ヶ月程度のトライアル期間を設けています。
Stripeで利用したAPI
Stripeで利用したAPIのリストです。
Subscription（サブスクリプション）：サブスクリプションのデータです。後述するPlanやPrice、Customerと紐づいて、有料プランの期間や遷移が保存されているデータです。
Plan（プラン）：プランのデータ。今回実装した「有料プラン」は、期間は違うものの中身は変わらないので『有料プラン』というデータです。
Price（料金情報）：価格のデータ。Planに紐づいて価格を設定することができます。月額プラン（980円） / 年額プラン（9,800円）のデータです。
Price Customer（顧客）：顧客の情報が入っているデータ。
PaymentMethod（カード）：カード情報が入っているデータ。
その他、支払情報（Payment Intent）、請求情報（Invoice）等のAPIも利用しているのですが、「有料プラン」（サブスクリプション）の実装に直接関係がある箇所ではないので割愛します。
Stripeで持つべきデータ、自社で持つべきデータ
Stripeで持つべきデータと自社で持つべきデータの棲み分けが、実装するうえで重要（悩む）ポイントかなと思います。Stripeと全く同じデータを持ち、整合性を保つのはデータ構造やデータ量の観点からかなりハードなので、ある程度のデータはStripe上に持っておきたいところです。
自社で持つべきデータの一例
- Stripeから参照するためのID群
Stripeデータの登録時に発行されたIDは自社DBに登録しておく必要があります。IDを持っておくことで、データの参照 / 更新 / 削除をAPI経由で行うことができます。エラーの際にログを取得したい時もIDが有効的です。以下、ID群の一例になります。
◯ subscription_id（Stripeが発行するサブスクリプションの一意のID）
◯ subscription_schedule_id（Stripeが発行するサブスクリプションスケジュールの一意のID）
◯ customer_id（Stripeが発行する顧客情報にアクセスするための一意のID）
◯ price_id（Stripeが発行する価格情報にアクセスするための一意のID）
- サービス内で参照されるデータ
私たちのようにWebサービスを運用している場合、ユーザーにより良い体験を提供するためにレスポンス速度が非常に大事になります。そのため、Stripeに都度APIリクエストを飛ばすようなレイテンシは極力なくしていきたいです。プラン内容によって利用できる機能が変わる等の場合は、該当するカラムに限って自社DBに持っておくことでリードタイムを減らすことができます。
Stripe側に任せるべきデータ
- クレジットカード情報
クレジットカードの加盟店はPCI-DSS準拠、またはカード情報の非保持化が必要になります。セキュリティの問題はプロバイダー（Stripe）に任せた方が、効率的に実装することができます。カード情報を顧客情報と紐づけておくことで、自動で顧客が保持するカード情報で決済を行ってくれます。
- サービス内で参照されないデータ
自社で持つべきデータと対象になるのですが、逆にサービス内で参照されないリアルタイムで必要ではないデータに関しては、Stripe側に任せておくのが良いと思います。例えば、経理で精算するための請求情報や支払い情報、次回の請求日などです。
最後に
INVOYに有料プランが導入された際に利用したStripeについてお話ししました。StripeはAPIのリファレンスも充実しているしダッシュボードも使いやすかったので、とても実装しやすかったです。データの持ち方がやや複雑になりそうですが、棲み分けをしっかりすればより利用価値を見出せると思います。
まとめ
OLTAでは、ユーザーに価値を提供し、事業を成長させるサービスを一緒に作る仲間を募集しています。 もし、この投稿にご興味を持っていただけたら、是非カジュアルにお話しさせてください。
