能書き
ソフトウェアを使うとき、データモデルを考えることが多い。必要だからというより、「楽しみ」である。間違っていることもあるし、途中で挫折することもある。でも、楽しみという観点では、間違っていることは大きな問題ではない。5 杯目のビールを飲んでいると思ったら、ハイボールだったからといって困ることはほとんどない。5 杯目の時点で、もう間違いだからだ。そして楽しい。翌朝のことは分からないけれど。
ともあれデータモデルである。この文書を読んだからといって、Stripe を利用したソフトウェアを実装する助けにはならないだろう。Stripe Connect の API を見ながら「あー、ここは、こういう風に抽象化するんだー。こういうデータモデルなんだー」と思ったりする。そういうことを今日から（うまくいけば、そして、上司や同僚に見とがめられなければ）25 日間、だらだらと綴る。吐露、であろう。
カバー画像は O RLY Cover Generator を作って、動物画像をさしかえた。あざす。
ライセンス
本文（カバー画像以外）は CC BY-SA 4.0 で公開する。
カバー画像の猫は CC BY-SA 4.0 で公開する。カバー画像の猫以外の部分は、O RLY Cover Generator に準ずる。
決済フロー as a Service
決済プラットフォーム Stripe には、Stripe Connect というサービスがある。このアドベントカレンダーは、Stripe Connect のデータモデルを理解していく試みだ。
世の中には、一対一の取引だけでは完結しないビジネスが存在する。フードデリバリーとか、EC プラットフォームとか、サービスのマッチングとか。Stripe Connect は、Buyer（購入者）、Platform（プラットフォーム）、Seller（販売者）という 3 者間の取引を想定している。Buyer がプラットフォームを経由して、Seller から何か商品（製品やサービス）を購入する。Buyer はプラットフォームに代金を支払い、プラットフォームが Seller に売上を手渡す。
取引の考え方として、プラットフォームが売上を一旦 Seller に渡してから、Seller から手数料を徴収すると考えてもいい。プラットフォームが受け取り、自分の取り分を手元に残して、Seller に渡すという取引で考えてもいい。このへんはサービスのあり方、会計などが影響するだろう。知らんけど。
資金の流れだけを追いかけると、下のようになる。
Buyer -> Platform <--> Seller
現金でやりとりするわけではなく、クレジットカードを使う場合を考えよう。受け取る側も現金ではなくて、銀行口座を使うことになる。すると、こうなる。
Buyer Platform Seller
Card -> Bank Account <--> Bank Account
取引というレイヤーでは、プラットフォームと Seller の間では、双方向のサービスと資金のやりとりがある。けれど、実際にお金を動かすときには、そしてビジネスが回っていれば、プラットフォームから Seller に払い出すだけになるだろう。たとえば毎月、Seller の商品による売上合計から、プラットフォームが提供したサービス手数料を差し引いて渡す。
Buyer Platform Seller
Card -> Bank Account -> Bank Account
Stripe Connect は、このような決済と資金分配を、software-defined で実行するサービスだ。
Buyer Platform Seller
Card Bank Account Bank Account
| ^ ^
v | |
---------------------------------------
Stripe
このようデータモデルと資金フローを見ていく。あなたの課題がどうすれば解決するか、という答えはおそらくない。しつこいけれど、ただの個人的な娯楽だからだ。
まとめ
以上で、長い能書きを終わる。この下に、ダサい免責事項もある。
次回は、まずはプラットフォームを忘れてみよう（ズコー）。購入者と Seller に 2 社の取引を見ていく。