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
480
toBサービスで外部決済サービスを導入し、うまくいったこといかなかったこと
Fumina Chihama
December 05, 2023
Tweet
Share
More Decks by Fumina Chihama
See All by Fumina Chihama
_配布資料商談力アップ_100社の経験に基づく初回商談の極意_Crevo.pdf
fumina
0
96
20241203_セミナー資料.pdf
fumina
0
85
"誰でも売れる"を体系的に整理!営業のプロが伝授する成功法則.pdf
fumina
0
41
Monoxer講演資料_書籍出版記念対談.pdf
fumina
0
66
DBの選び方LT
fumina
2
240
Azure OpenAI を活用して金融機関にお届けする LLM + RAG サービス
fumina
1
370
RAGを活用した動画学習コンテンツの推薦 ~実装の工夫と課題~
fumina
0
550
RAGの基本と最新技術動向
fumina
0
810
二刀流で切り開くRAG活用術
fumina
0
380
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
VelocityConf: Rendering Performance Case Studies
addyosmani
326
24k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Into the Great Unknown - MozCon
thekraken
33
1.5k
How to Think Like a Performance Engineer
csswizardry
22
1.2k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Fireside Chat
paigeccino
34
3.1k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
The Art of Programming - Codeland 2020
erikaheidi
53
13k
How to Ace a Technical Interview
jacobian
276
23k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
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
これからの展望と課題 ・複数既存プロダクト、新規プロダクトを考慮し、お客様にとってシンプルで便 利な決済基盤の提供 すでにあるプロダクトのアカウントが分けられており、このマージは構造上難しそうなので、アプリケーション で上手くデータをマージして、それを提供する必要がある?