toBサービスで外部決済サービスを導 入し、うまくいったこといかなかったこと 株式会社overflow 磯崎慶太 

磯崎慶太 Keita Isozaki 2015年にアメリカで家庭料理の売買 サービスで起業、その後フリーランス として、社内システム開発からモバイ ルアプリ開発まで色々な開発を経た 後、ヘルスケアで再度起業。 2018年 に株式会社overflowに参画。 

Service 

Architecture Frontend Backend Analysis/DataMining API Layer Application Layer Database Layer 3rd Party metadata Web Server API Offers OFM ID, Auth 認証・認可 Offers OFM Offers OffersMGR PoC,Micro SaaS プロダクト分析/ アクション実行 推薦エンジン/ MLやデータ分析 DataProcessing/ Recommend 

Stripeを使ってどんなことをしているのか Offers 

新規契約 ‐ Stripeとの接点 Salesforce Offers Stripe 商談作成 契約書下書き作成 Cloudsign作成 契約データ作成 Cloudsign API Cloudsign締結後、利 用開始日に登録 フォームを送信 Billing Customer Stripe Element Stripe Billing 登録フォームの送 信時に作成 

新規契約 ‐ Stripeとのデータ同期 Salesforce Offers Stripe Billing Customer Stripe Billing 契約データ 企業データ 請求データ プランデータ 契約履歴データ API Webhook プランマスター 商談データ 顧客データ プランデータ 同データを手動で管 理 Plan 

Stripeを使ってうまくいったこと Offers 

Offers ‐ Stripeを使ってうまくいったこと ・複数月のサブスクリプションの決済が簡単に導入できた ・請求書とクレジットカード払いの併用ができ、予め用意していたプラン以外 での契約も柔軟に対応ができた 

Stripeを使ってうまくいかなかったこと Offers 

Offers ‐ Stripeを使ってうまくいかなかったこと ・変化するビジネス要件に即座に柔軟に対応できる構成になっていなかった → 例えば、新料金プラン導入、新たな期間のプランを導入する時に柔軟に 追加変更できる構成になっていなかった 

新規契約 ‐ Stripeとのデータ同期 Salesforce Offers Stripe 契約データ 企業データ 請求データ プランデータ 契約履歴データ API Webhook プランマスター 商談データ 顧客データ プランデータ 同データを手動で管 理 アプリケーション内 でStripeの商品に依 存する処理が多数 あり、一つの変更で もそこそこ時間が取 られてしまう Billing Stripe Billing Plan Customer 

Offers ‐ Stripeで決済基盤を作り、運用してきてわかったこと ・変化するビジネス要件に対応するためには、なるべく決済に関する処理を アプリケーションに持ち込まず、必要最低限にする 決済ステータスや決済情報に基づく認可などはアプリケーションで行い、決済情報の入力や更新、サ ブスクリプションの更新などそれ以外の決済に関する処理は Stripeの提供するものやフローに則って 行う形が作れればベスト ・同時に初期実装・運用コストを抑えるために、Stripeが提供しているものは できるだけ使えるだけ使う 例: checkoutやカスタマーポータル 

Stripeを使ってどんなことをしているのか Offers MGR 

新規契約 ‐ Stripeとの接点 Hubspot Offers MGR Stripe 商談作成 商談取り込みと承認 契約データ作成 利用開始日に登録 フォームを送信 Billing Customer Stripe Checkout Stripe Billing 決済情報入力段 階でcheckoutに 遷移 

登録後 ‐ Stripeとの接点 Offers MGR Stripe Billing Customer Stripe Checkout Stripe Billing Stripe Element 請求書→クレ ジットカード払い への変更 Stripe カスタ マーポータル トライアルプラン の有料申し込み クレジットカードや 請求先情報の変 更 支払履歴の確認 

新規契約 ‐ Stripeとのデータ同期 Hubspot Offers MGR Stripe Billing Customer Stripe Billing 契約データ 企業データ 請求データ プランデータ Webhook 商談データ Plan 

Offersでの運用から学び、変わった部分 ・無闇にAPIを叩かない。Stripeのwebhookのみを使用し、支払いステータスなど のデータ同期のみを行う プラン情報や決済情報はすべて Stripeで管理し、アプリケーションで管理する情報は必要最低限に ステータスや決済状況に応じた認可の処理などはアプリケーション側で記述する ・とにかく、Stripeが提供しているもので使えるものは使う 登録時、クレジットカード情報変更時は checkoutを使用 クレジットカード情報の変更や、支払い履歴の確認は全てカスタマーポータルで確認できるように 

Stripeを使ってうまくいったこと Offers MGR 

Offers MGR ‐ Stripeを使ってうまくいったこと ・爆速でクレジットカード決済が導入できた ・トライアルも爆速で導入できた ・プラン変更対応にもコストを掛けずに対応できている 

Stripeを使ってうまくいかなかったこと Offers MGR 

Offers MGR ‐ Stripeを使ってうまくいかなかったこと ・Offers MGR単体では特にない ・Offersとの共通決済基盤を作りたかった（作りたい） → 1つの共通顧客IDで複数サービスの商品の管理、支払手段の編集や確認ができること すでに1つ目のサービスのアカウントがある状態で、２つめのアカウントはどのように作る？ 2つ目のサービスでのStripe導入時に、1つ目のサービスと同アカウントで管理するかどうかの選択を迫られ た。 すでにStripeを導入していた1つ目のサービス側でStripeとアプリケーションが密に結合しており、 1アカウン トで複数サービスの商品を扱う設計にリスクが有り、この選択肢は取らなかった。 

これからの展望と課題 Offers × Offers MGR 

これからの展望と課題 ・複数既存プロダクト、新規プロダクトを考慮し、お客様にとってシンプルで便 利な決済基盤の提供 すでにあるプロダクトのアカウントが分けられており、このマージは構造上難しそうなので、アプリケーション で上手くデータをマージして、それを提供する必要がある？