アプリの進化に伴って変化 してきた Stripe 利用方法 The Designium, Inc.
 伊藤勇希
 @acomagu
 231215 JP_Stripes


Samurai.MaaS とは？

Samurai.MaaS とは？ - 会津若松地域で展開している MaaS アプリ(PWA)
 - 生活 MaaS(その地域を日常的に利用する方向け機能)と、観光 MaaS(観光客向け 機能)を統合していることが特徴


バスの現在地/運行状況表示
 交通チケットの購入
 観光地情報


会津 MaaS 事業の変遷 2018 年: おすすめスポットへの公共交通機関を使用したナビ&交通チケットの販売
 2019 年: 国交省新モビ事業に採択 / 観光地向けアプリ / 会津 Samurai.MaaS 事業会 へ
 2020 年: 同上 / 観光地型だけではなく生活型も統合を目指す
 


No content

ステークホルダーが多い

2019年: 観光客向けアプリ時代 - 会津若松地域への観光客向けに、おすすめスポット/ルー ト検索/交通チケットを販売するアプリ
 - 自分が関わったのはこのアプリに Stripe を導入する検証 から
 - この時はサーバー無しで Stripe と統合していた
 - Payment Request API(ブラウザから Apple Pay や Google Pay 等を呼び出せる API)が出始めた頃で、Android 端末で はうまく動くが iOS でうまく動かなかったため、Android 端 末には Stripe.js v3 を、iOS 端末には Stripe.js v2 を出し分 けたりしていた


No content

すごいスピードで実装できた

なぜ高速に実装できたか？ - DB 無しで実装
 - Stripe の Metadata を活用し Auth0 のユーザー ID と紐づけた 
 - 購入履歴を都度 Stripe から取得するように 
 - Stripe のドキュメントが神だった
 - そもそも決済代行業者はドキュメントが機密扱いのところが多い -> 第三者によるノウハウが公開されない&非公式ライブラリもコ ミュニティも育たない 
 - Stripe のサポートが神だった
 - とにかく日本語サポートが丁寧 
 なんでも検証してくれる 
 - 英語のチャットサポートも活用したが、正直それ以上に感じたのは 日本語のサポートが丁寧で早い 
 - 無料なので活用しまくろう 


2020年: Samurai.MaaS 誕生 - 「会津 Samurai MaaS 協議会」発足(2019年)


2020年: 支払い周りでの変更 - 交通チケットだけでなく、アクティビティ(体験など)や食事の割引券等もセットで販売 することに
 - 複数「商品(チケット)」をまとめて購入するユースケース 
 - 「商品」の管理を行う必要が出てきた
 ↓
 - Stripe の Product を商品のマスタとし、Dashboard から管理するように
 - Stripe Checkout の採用
 - フロントで Product の SKU と共に redirectToCheckout を呼び出す(Checkout の作成をフロントで 行う)
 - 何が得られたか？: フォームを作る手間の軽減 / 楽に安全な決済処理を作成できた / ユーザーが 購入商品を最終チェックできる / 決済時のサーバーサイドの実装ゼロ 


2020年: 支払い周りでの変更 - 外部チケットシステム(ひたち MaaS)との統合
 - 商品数の増加
 - 複数人分のチケットを購入したときに、「チケット(商品)の〇個の購入」として扱うの ではなく、「〇人分のチケット1つの購入」として扱うように変更
 - チケットリストのレスポンスが遅いというフィードバック
 ↓
 - Stripe の Product で管理するのを辞め、独自の CMS で管理するように
 - 料金はサーバー側で計算し、Checkout を発行するように
 - ユーザーごとに Customer をきちんと作るようにし、Charges リストを customer_id で引くようにする(それまでは全件取って metadata でフィルタしていた)


2021年: 支払い周りでの変更 - 「割引キャンペーン」の実装
 - 「バス等の予約機能」の実装(この時点では「予約機能が将来的に入るかも」という 情報だけで具体的にどんな予約なのかはふわっとしたまま)
 - 返金機能の実装


2022年: 宿予約機能の追加 - Samurai.MaaS とは別の宿予約アプリを Samurai.MaaS と同じバックエンドで実現し たいという要望
 - 将来的には交通チケットを宿予約アプリでも予約できるようにするため 
 - 予約機能
 - キャンセルポリシーの実装
 - キャンセル時に何日前かによって、キャンセル料の割合を決定する 
 ↓
 - キャンセル料が発生するタイミングまではオーソリだけを取り、発生するタイミング になったらキャプチャする
 


2022年: 宿予約機能の追加 - 料金変更機能の実装
 ↓
 - 決済後に料金が増えたり減ったりするユースケースに対応するため、複数の Payment Intent をまとめて管理する仕組みを実装
 Checkout の setup_future_usage: “off_session” を活用
 料金が増えた場合は Checkout 時の Payment Method を利用して Payment Intent を新たに作成し、減る場合は金額が小さい順にキャンセル(or 部分返金)する


2023年: 宿予約機能の追加 - 「予約時に金額が確定していない」ユースケースに対応
 - 宿管理者が予約を確認したのちに、手動で金額を設定してもらう機能 
 ↓
 - 金額が未定の場合は Checkout ではなく Setup Intents を利用しカード情報のみ収 集しておくように
 金額確定後に自動決済


2023年: Stripe Connect 導入 - 以前は Samurai.MaaS で得られた収益を手作業で各チケットを提供する事業者に 分配していたが、
 扱う金額や関わる事業者が増え、利益の分配作業が大変になってきた
 ↓
 - Stripe Connect を導入することに
 - 各事業者さんに Stripe の Express Account を作成してもらい、Account ID を商品と紐づけておく 
 - 実装が簡単すぎてびびった 


Stripe に支えられてきた Samurai.MaaS の成長 - PoC を爆速で作成できた
 - Elements から Checkout に移行した
 - 途中から Customer を利用しはじめた
 - Product を使うのを辞め独自 CMS に移行した
 - 複数 Payment Intents を扱うようになった
 - Checkout の代わりに Setup Intents も利用するようになった
 - 売上の分配を簡単にするために Connect を導入した


Stripe に支えられてきた Samurai.MaaS の成長 - PoC を爆速で作成できた
 - Elements から Checkout に移行した
 - 途中から Customer を利用しはじめた
 - Product を使うのを辞め独自 CMS に移行した
 - 複数 Payment Intents を扱うようになった
 - Checkout の代わりに Setup Intents も利用するようになった
 - 売上の分配を簡単にするために Connect を導入した
 ↑Stripe 柔軟すぎない？


こういうの多くないですか？ A
 いろいろ代わりにやってくれるし 
 簡単だけど
 複雑なことはできないよ
 
 B
 あらゆる機能を備えていて
 いろいろできるけど大変だよ
 上級者向け
 
 ↑どちらか選べ！↑


こういうの多くないですか？ Easy
 いろいろ代わりにやってくれるし 
 簡単だけど
 複雑なことはできないよ
 
 Simple
 あらゆる機能を備えていて
 いろいろできるけど大変だよ
 上級者向け
 
 ↑どちらか選べ！↑


Stripe は Easy & Simple である - Stripe は決済をとても Easy にする。しかし、結果 Simplicity を失ってもいない。
 - e.g. Checkout(Button)が出てきたのは 2013 年、Payment Intents が出てきたのは 2017 年 
 (Payment Intents が存在しない Checkout を想像できるか？) 
 - Easy を目指し、新機能を追加し、 
 しかし Simplicity へのたゆまぬ努力も続けている 
 - Simple だと何がいいのか？
 - ユーザーの創造性を引き出すことができる(仮説→試行→歓喜) 
 - Easy - Complex なものは、特定のユースケース以外では使うことが難しくなりがち 
 - 一度 Stripe API のモデルを学んでしまえば、自然といろいろな使い方ができるようになっている 
 これは Stripe API の大部分が直感に反しない、理解しやすいものにデザインされているから 
 - e.g. 「Setup Intents も Checkout と同様に Payment Method を作成するはずだから、Checkout から Setup Intents に置き換えてもそこまで問題にならないはず」 


つまり...? - Stripe は「簡単に初められて、拡張にも強い」
 - ありふれたものは簡単に作ることができる。ニッチなカスタマイズも漸進的に行うことができる 
 - なぜそれができるの？
 - API モデルが明瞭である 
 - 理解しやすく、予想外の挙動が少ないため、変更へのハードルが低い/容易 
 
 さらに...
 - 購入に関係する多くのものは用意されている 
 - Customer、Product、Price など、決済のコアではないモデルも用意されているため、ここに 乗っかることもできる 
 - ドキュメントが詳細である/サポートが優れている 
 
 Samurai.MaaS の成長は Stripe に助けられてきました🙏🙏🙏


まとめ - デザイニウムは地域の交通や観光を包括的に促進するアプリ
 「Samurai.MaaS」を頑張って開発しています！
 - Stripe の API は「簡単に始められて、拡張にも強い」デザインがされているように 感じます
 - Easy & Simple で、明瞭な API モデル 
 - 購入に関係するものは大方用意してくれている 
 - ドキュメントが公開されていて、詳細で、サポートも素晴らしい！ 
 - ↑こんな Stripe に支えられて Samurai.MaaS は成長してきました


ありがとうございました！