この記事は2021年12月時点のStripe製品情報に基づいた内容となります。

この記事はStripe Connectを実装する際に決済以外の考慮点を紹介していきます。ある程度公式のドキュメントを読んだ前提で書いています。対象となる読者はStripe Connectを活用して製品・事業を検討しているプロダクト / プロジェクトマネージャーを想定しています。テクニカルな内容より上流設計の内容がメインとなっています。

##お金の流れ - FundsFlow
顧客 → プラットフォーム → 店子という流れは一番最初に考えると思いますが、「よし頑張ろう」になる前もう一度本当にこれだけなのか整理することをお勧めします。例として3パターンを挙げます。

1.店子にも有償サービスを提供したい
分かりやすい例としては「有償テーマ・テンプレート」かと思います。
この場合、店子（顧客）→ プラットフォームという流れになります。ConnectのAPI実装と異なりますので分けて工数見積しましょう。

2.他のところからの入金したい
すでにビジネスを展開しているプラットフォームだと、複数の決済代行業者を利用したり、現金決済があったりします。店子への入金をまとめたほうが効率上がりますし、ユーザー体験もいいと思います。その場合は一旦Stripe外で決済が終了していますので、プラットフォーム銀行口座 →（Top Up）プラットフォーム →（Tranfer）店子という流れができます。

3.複数の支払対象が存在する
Stripe Connectは決済した金額を手数料を差し引いて店子に送金するためにDestination ChargeとSC&T (Separate Charge & Transfer)という2種類のアプローチを提供しています。（参考）

詳細はドキュメントを見てほしいですが、ざっくりな違いとしては：

Destination Charge	SC&T
決済と同時に店子を指定して送金するため、手数料を決めればいくら送金するのが自動的に計算される。ただ、店子を一つしか指定できない。	決済したら全額をプラットフォームが保持して、いくら送金するのがプラットフォーム側が後で計算する。送金対象は複数でもOK。
複数の支払対象がある場合、送金額の計算ロジックやTranferの実装が必要ですので、忘れず開発スコープに入れましょう。

##店子登録 - Onboarding
Stripe Connectを利用するには顧客確認(KYC)が必要です。ここで注意してほしいのは独自で情報を収集している既存ビジネスです。社内で情報集取しているし、StripeのAPIで諸々登録できるから安心しているかもしれませんが、収集している書類が期限切れで収集し直す必要が出てくる可能性がありますので、特に店子が多い場合、早めに計画しないとカスタマーチームがパンクします。

##不正利用 - Dispute
既存ビジネスなら現在の不正利用率である程度参考できますが、新しい事業の場合は見落としやすいです。「不正利用を防ぐ」と「不正利用発生した時の対応」で紹介します。

「不正利用を防ぐ」
多くのビジネスはRadar Standardバージョンの機械学習モデルを利用すれば大半の不正利用をブロックできますが、実装によって機械学習が正しくパフォーマンスを発揮できない場合もあります。公式にあるこちらの**チェックリストはゼッタイ漏れないでほしい**。特にStripe.jsは多くのシグナルを集取していますので、忘れずチェックしましょう。

Radar For Teams（RFT）という色々カスタマイズルールを定義できる有償プランを最初から利用する場合、Metadataの活用をお勧めします。RFTはルールとして利用できる標準属性以外にCustomer Object、PaymentIntent ObjectにあるMetadataもルールとして利用できます。例えば特に狙われやすい「限定商品・コラボ商品」に対してReview if ::Category:: = ‘Premium’ AND :charge_attempts_per_customer_hourly: > 3で一時間三回以上購買行為しているユーザーをレビューに回すような設定ができます。
日本では3Dセキュアが必須となっているIssuerが現状ほとんどいません。「コンバージョン率が下がるから使いたくない」と思っている方が多くいる印象です。RFTを使えば、ほとんどのトランザクションを影響せず、特定なケースで一回だけチャレンジする事が可能です。例えば、95%の顧客は一時間以内に1、2回の購買行為しかしないであれば、:auths_per_customer_hourly:=2というルールを設定すると該当顧客の一時間以内の3回目の決済だけ3DSが起動されます。ちゃんと通せば4回目以降3DS起動されません。通れなかったらカウンターが3のままですので、毎回3DS起動されます。レビューのルールと組み合わせばこれだけでも不正利用者を絞り出せます。

「不正利用発生した時の対応」
不正利用の中にFriendly fraudsters（本人利用したのにチャージバックを申請している）がありますので、反証資料を提出します。提出する内容は不正利用のカテゴリによって異なります。（参考）Stripeのダッシュボードから反証資料を提出できますが、やっぱり一々ゼロから入力するのがとても効率が悪いです。ビジネスの規模が大きくなるとどうしても放置されがちです。ここでお勧めしたいのはAPIによる反証資料の半自動化です。DisputeオブジェクトはAPIでEvidence（反証資料）をアップデートできますので、毎回必ず固定で入れる項目（名前、住所、メールアドレスなど）はWebhookから検知して自動的にAPIで入れて本当に人間の判断が必要な部分に絞れます。業界によって、APIで全自動で反証資料を提出するところもあるようです。

##入金 - Payout
Stripeの入金スケジュールは自動入金と手動入金がありますが、プラットフォームビジネスの場合、店子への入金体験が大切だと思います。特に店子が並行で複数のプラットフォームで同時に稼働できないような事業なら一層大事かと思います。

Stripeの日本での入金スケジュール：

週に 1 回 (選択した曜日に) 入金が行われ、入金には 4 営業日前までに処理された売上が含まれます。JCB、ダイナースクラブ、およびディスカバーによる支払いは、4 営業日ではなく 30 日後に入金への利用が可能になります。

現在JCB、ダイナースクラブ、およびディスカバー（まとめてJCB決済と言います）の入金スケジュールが30日間ですので、月次自動入金の場合、JCB決済分は約2ヶ月待たせる可能性があります。（例：毎月25日入金を設定した場合、3月29日に発生したJCB決済は4月25日に間に合わないため、5月25日に入金されます）

入金に関する考え方としてはJCBの入金体験とプラットフォームのオペレーション負荷のトレードオフになるかと個人的に思います。

評価項目/アプローチ	1.週次・月次自動入金	2.月次手動入金	3.週次手動入金
JCB決済の扱い方	他のカードブランドと別サイクル	他のカードブランドと同じサイクル	他のカードブランドと同じサイクル
プラットフォーム負荷	◎ Stripe側の設定のみ	△ 入金額の計算・入金スケジュール制御ロジック	☓ No.2の内容 + 残高のハンドリング + Supportability確認
店子の体験	☓ （JCB決済の売上が別スケジュールで入金）	△ （月次入金）	◎ （週次入金）
説明	毎月の入金額は自動的に計算されますし、入金と決済の紐づきも分かるため、プラットフォームとしては一番楽です。	毎月25日締めで翌月月末払いというルールで内部システムで先月の売上を計算するロジックを用意する必要があります。入金のタイミングも月末が祝日の場合を考慮する必要があります。また、手動入金ですので、決済との紐づきがないですので、会計上の突合が一手間掛かります。	基本的な考え方はNo2と同じですが、ある程度の決済ボリュームと更に細かい残高の管理が必要です。また、場合によってJCB の早期入金ベータ版利用します。

上記いずれのパターンにしても明示的に利用規約に反映してください。JCB の早期入金ベータ版で決済コストが高くなりますが、店子獲得コストが非常に高い業界の場合は逆にアドバンテージになるかもしれません。

##まとめ
プロジェクトを推進する前に以下考慮点を入れると少しでも人月の神話状態を避けられます。

お金の流れを整理して本当に単純な顧客 → プラットフォーム → 店子だけなのか確認します。他にあったら実装方法を確認して計画に入れます。
店子の情報は独自で集取していてもConnectに必要な項目を入念に確認します。（特に免許書の期限切れが要注意）
Radar Standardの場合でも**チェックリスト**にある内容をしっかり実装します。
Radar For Teamsを利用するならMetadataの項目を検討します。顧客の購買行為と不正利用との関連性を特定してエッジケースに3DSの利用を検討します。
競合、社内開発・運用リソースや店子への入金体験を総合的に考慮した上、入金のアプローチを決定します。

##参考

Stripe Connect Data Models and Fund Flows
公式支払いを作成する
公式必要な確認情報
公式ルールリファレンス
公式入金の受け取り