Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
toBサービスで外部決済サービスを導入し、うまくいったこといかなかったこと
Search
Fumina Chihama
December 05, 2023
0
460
toBサービスで外部決済サービスを導入し、うまくいったこといかなかったこと
Fumina Chihama
December 05, 2023
Tweet
Share
More Decks by Fumina Chihama
See All by Fumina Chihama
Monoxer講演資料_書籍出版記念対談.pdf
fumina
0
53
DBの選び方LT
fumina
2
240
Azure OpenAI を活用して金融機関にお届けする LLM + RAG サービス
fumina
1
340
RAGを活用した動画学習コンテンツの推薦 ~実装の工夫と課題~
fumina
0
490
RAGの基本と最新技術動向
fumina
0
730
二刀流で切り開くRAG活用術
fumina
0
350
営業組織から「がんばっているのに売れない」 をなくす、たった1つの”急所”とは
fumina
1
130
事業の進化とデータ構造で苦しんだ話
fumina
0
220
香りECスタートアップにおける データの更新によって生まれた データ負債事例と学び
fumina
0
450
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
45
6.8k
Speed Design
sergeychernyshev
25
620
For a Future-Friendly Web
brad_frost
175
9.4k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.3k
Rails Girls Zürich Keynote
gr2m
94
13k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.3k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Producing Creativity
orderedlist
PRO
341
39k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
The Pragmatic Product Professional
lauravandoore
31
6.3k
Transcript
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つめのアカウントはどのように作る?
2つ目のサービスでのStripe導入時に、1つ目のサービスと同アカウントで管理するかどうかの選択を迫られ た。 すでにStripeを導入していた1つ目のサービス側でStripeとアプリケーションが密に結合しており、 1アカウン トで複数サービスの商品を扱う設計にリスクが有り、この選択肢は取らなかった。
これからの展望と課題 Offers × Offers MGR
これからの展望と課題 ・複数既存プロダクト、新規プロダクトを考慮し、お客様にとってシンプルで便 利な決済基盤の提供 すでにあるプロダクトのアカウントが分けられており、このマージは構造上難しそうなので、アプリケーション で上手くデータをマージして、それを提供する必要がある?