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
440
toBサービスで外部決済サービスを導入し、うまくいったこといかなかったこと
Fumina Chihama
December 05, 2023
Tweet
Share
More Decks by Fumina Chihama
See All by Fumina Chihama
DBの選び方LT
fumina
2
230
Azure OpenAI を活用して金融機関にお届けする LLM + RAG サービス
fumina
1
310
RAGを活用した動画学習コンテンツの推薦 ~実装の工夫と課題~
fumina
0
440
RAGの基本と最新技術動向
fumina
0
670
二刀流で切り開くRAG活用術
fumina
0
330
営業組織から「がんばっているのに売れない」 をなくす、たった1つの”急所”とは
fumina
1
130
事業の進化とデータ構造で苦しんだ話
fumina
0
210
香りECスタートアップにおける データの更新によって生まれた データ負債事例と学び
fumina
0
450
OWASPの歩き方
fumina
1
630
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
231
17k
Git: the NoSQL Database
bkeepers
PRO
425
64k
Navigating Team Friction
lara
183
14k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
290
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Thoughts on Productivity
jonyablonski
67
4.3k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
107
49k
Fontdeck: Realign not Redesign
paulrobertlloyd
81
5.2k
Code Reviewing Like a Champion
maltzj
519
39k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
32
1.8k
The Cult of Friendly URLs
andyhume
78
6k
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
これからの展望と課題 ・複数既存プロダクト、新規プロダクトを考慮し、お客様にとってシンプルで便 利な決済基盤の提供 すでにあるプロダクトのアカウントが分けられており、このマージは構造上難しそうなので、アプリケーション で上手くデータをマージして、それを提供する必要がある?