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
420
toBサービスで外部決済サービスを導入し、うまくいったこといかなかったこと
Fumina Chihama
December 05, 2023
Tweet
Share
More Decks by Fumina Chihama
See All by Fumina Chihama
DBの選び方LT
fumina
2
200
Azure OpenAI を活用して金融機関にお届けする LLM + RAG サービス
fumina
1
270
RAGを活用した動画学習コンテンツの推薦 ~実装の工夫と課題~
fumina
0
330
RAGの基本と最新技術動向
fumina
0
530
二刀流で切り開くRAG活用術
fumina
0
260
営業組織から「がんばっているのに売れない」 をなくす、たった1つの”急所”とは
fumina
1
130
事業の進化とデータ構造で苦しんだ話
fumina
0
180
香りECスタートアップにおける データの更新によって生まれた データ負債事例と学び
fumina
0
420
OWASPの歩き方
fumina
1
580
Featured
See All Featured
Thoughts on Productivity
jonyablonski
66
4.2k
A designer walks into a library…
pauljervisheath
201
24k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
36
2.1k
BBQ
matthewcrist
83
9.2k
How to name files
jennybc
75
98k
The Pragmatic Product Professional
lauravandoore
31
6.2k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
225
22k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
166
48k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
43
2k
RailsConf 2023
tenderlove
28
810
Optimising Largest Contentful Paint
csswizardry
31
2.8k
The Brand Is Dead. Long Live the Brand.
mthomps
53
38k
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
これからの展望と課題 ・複数既存プロダクト、新規プロダクトを考慮し、お客様にとってシンプルで便 利な決済基盤の提供 すでにあるプロダクトのアカウントが分けられており、このマージは構造上難しそうなので、アプリケーション で上手くデータをマージして、それを提供する必要がある?