Summary

  • 返金やチャージバックは、まず決済を受けた連携アカウントから支払われる。出店者の損失をプラットフォームが負い、出店者側の資金が足りなければ、Stripe は運営側で reserve_transaction を作る。運営側の利用可能残高も不足すれば、連携銀行口座からの引き落としを開始する。
  • 出店者の赤字が縮めば準備金は運営側へ戻り得る。180日残り続けた赤字には connect_collection_transfer が使われ、準備金から出店者口座へ資金を移して赤字をゼロにする。

店舗の引き出しが本部の金庫を開ける

ある店舗の売上に対する返金が生じる。通常、資金を出すのはその決済が載った連携アカウントだ。Stripe の説明では、その出店者のマイナス残高についてプラットフォームが損失責任を持ち、出店者の Stripe 残高や連携銀行口座で賄えない場合、運営側の資金が使われる。店舗の問題が本部に届くのは、約款の片隅の抽象語ではなく、帳簿の具体的な移動だ。

出店者口座がマイナスになると、運営側に reserve_transaction が記録される。運営側の利用可能残高で足りるなら、そこから準備金を積む。足りなければ残高はマイナスに入り、Stripe は連携銀行口座から不足分を引き落とし始める。すべての返金に銀行口座が登場するわけではない。責任設定と、出店者・プラットフォーム双方の資金状態が分岐点になる。

Accounts v2 では、この責任は defaults.responsibilities.losses_collector に表れる。application は連携アカウントのマイナス残高をプラットフォームが負う設定、stripe は Stripe が負う設定だ。後者でも運営側は自分自身の口座のマイナス残高には責任を持つ。Stripe は Merchant 設定を加える際にこの値を決め、その後は変更できないと説明している。出店審査は販路を増やす手続きであると同時に、誰の赤字を背負うか決める手続きでもある。

準備金は固定額ではない。Stripe によれば、対象出店者のマイナス残高の合計に概ね対応し、データ反映の遅れで差が出る。出店者の新しい売上などで赤字が縮めば、調整が生じて準備金が運営側の利用可能残高へ戻る。一方、赤字が180日続くと connect_collection_transfer が準備金を連携アカウントへ移し、そこをゼロにする。運営側が先に送金して赤字を埋める道もあるが、その原資も運営側だ。時間が損失を消すわけではない。

公開文書に特定のプラットフォームの借入額や実際の銀行引き落としはない。個別事例に必要なのは責任設定、返金・争議、準備金の記録、銀行の動きである。市場の構造はもう見えている。売上に応じた手数料を取るプラットフォームが、場合によっては出店者に自分の流動性まで貸している。値付けと上限を別々に考える余裕はない。

Sources