Chapter 01

はじめに

Toru Furukawa
Toru Furukawa
2021.11.30に更新

能書き

ソフトウェアを使うとき、データモデルを考えることが多い。必要だからというより、「楽しみ」である。間違っていることもあるし、途中で挫折することもある。でも、楽しみという観点では、間違っていることは大きな問題ではない。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 社の取引を見ていく。