支払いと送金別方式を作成する
プラットフォームアカウントで支払いを作成し、複数の連結アカウントに売上を送金できます。
「支払いと送金を別々」に作成して、1 つの支払いから複数の連結アカウントに資金を送金する場合や、支払い時に特定のユーザーが不明な場合に送金します。プラットフォームアカウントへの支払いは、連結アカウントへの送金から切り離されます。この支払いタイプでは、次のようになります。
- プラットフォームのアカウントで支払いを作成し、売上を連結アカウントに送金します。この支払いは、ご自身のアカウントでの支払いとして表示され、さらに連結アカウントへの送金も表示されます (金額はご自身で決定します)。この金額はアカウント残高から引き落とされます。
- 複数の連結アカウントに売上を送金できます。
- Stripe の手数料、返金、チャージバックは、お客様のアカウント残高から引き落とされます。
この支払いタイプは、レストランのデリバリープラットフォームである DoorDash のように、複数の当事者間で支払いを分割する必要があるマーケットプレイスに最適です。
Stripe は以下の国で、支払いと送金別方式に対応しています。
多くの場合、プラットフォームと連結アカウントは同じ地域に所在している必要があります。許可されていない越境送金を試みると、エラーが返されます。複数地域間での送金のサポートについては、越境送金をご覧ください。送金は、支払い、トップアップ、手数料の許可されたユースケースと併用する場合にのみ利用できます。Express ダッシュボードにアクセスできる連結アカウント、またはダッシュボードにアクセスできない連結アカウントは、支払いと送金別方式を利用することをお勧めします。
プライベートプレビュー
リージョン間の支払いと送金別方式を使用する機能は、プライベートプレビュー版で以下のシナリオにご利用いただけます。
- プラットフォームがイギリスまたは EU にあり、連結アカウントがアメリカにあります。
- プラットフォームがアメリカにあり、連結アカウントがイギリスまたは EU にあります。
アクセスをリクエストするには、お問い合わせください。
Stripe Checkout を使用して、Stripe がオンラインで提供する決済ページにリダイレクトします。この実装と、Stripe の他の実装タイプとの比較をご覧ください。
まず、Stripe アカウントを登録します。
アプリケーションから Stripe API にアクセスするには、Stripe の公式ライブラリを使用します。
Checkout セッションを作成するクライアント側サーバー側
Checkout Session (Checkout セッション) は、ラインアイテム、注文金額と通貨、および受け付け可能な支払い方法など、支払いフォームで顧客に表示される内容を制御します。サーバー側のエンドポイントを呼び出して、Checkout セッションを作成する購入ボタンをウェブサイトに追加します。
<html> <head> <title>Checkout</title> </head> <body> <form action="/create-checkout-session" method="POST"> <button type="submit">Checkout</button> </form> </body> </html>
サーバー側で Checkout セッションを作成し、レスポンスで返された URL に顧客をリダイレクトします。
line_
: この属性は、顧客が購入しようとしているアイテムを表します。このアイテムは Stripe がオンラインで提供する購入ページに表示されます。items payment_
: 一意の文字列をintent_ data[transfer_ group] transfer_
として使用し、相互に関連付けるオブジェクトを識別します。Stripe は、group transfer_
値を指定して PaymentIntent の支払いを自動的に作成する際、同じ値を支払いのgroup transfer_
に割り当てます。group success_
: Stripe は、顧客が支払いを完了した後に成功時の URL にリダイレクトし、url {CHECKOUT_
の文字列を Checkout セッションの ID に置き換えます。この ID を使用して Checkout セッションを取得し、ステータスを確認して、顧客に表示する内容を決定してください。自社で使用するクエリパラメーターを追加することもできます。このパラメーターはリダイレクトプロセス全体にわたって存続します。詳細については、Stripe がオンラインで提供するページでリダイレクトの動作をカスタマイズするをご覧ください。SESSION_ ID}
支払い後のイベントを処理するサーバー側
支払いが完了すると Stripe は checkout.session.completed イベントを送信します。Webhook を使用してこのイベントを受信し、顧客への注文確認メールの送信、データベースへの売上の記録、配送ワークフローの開始などのアクションを実行します。
クライアントからのコールバックを待つのではなく、これらのイベントをリッスンします。クライアント側では、コールバックの実行前に顧客がブラウザーのウィンドウを閉じたり、アプリケーションを終了したりする可能性があります。また、支払い方法によっては支払いの確定までに 2 ~ 14 日かかることがあります。自社の構築済みのシステムで非同期イベントをリッスンするように設定すると、一度の導入で複数の支払い方法に対応できるようになります。
Checkout で支払いを回収するときは、以下のすべてのイベントを処理することをお勧めします。
イベント | 説明 | 次のステップ |
---|---|---|
checkout.session.completed | 顧客が Checkout フォームを送信して、決済を正常に承認しました。 | 決済の成功または失敗の結果を待ちます。 |
checkout.session.async_payment_succeeded | 顧客の決済が成功しました。 | 購入された商品やサービスのフルフィルメントを行います。 |
checkout.session.async_payment_failed | 何らかの理由により決済が拒否されたか、失敗しました。 | 顧客にメールで連絡して、新たに注文するように依頼します。 |
これらのイベントのすべてに、Checkout Session (Checkout セッション) オブジェクトが含まれています。決済が成功すると、基となる PaymentIntent のステータスが processing
から succeeded
または失敗のステータスに変わります。
送金を作成するサーバー側
サーバーで、Transfer (送金) を作成し、使用する transfer_
を指定することで、アカウントから連結アカウントに送金します。
送金額と支払い金額が一致している必要はありません。1 回の支払いを複数の送金に分割したり、複数の支払いを 1 回の送金に含めることができます。以下の例では、同じ transfer_
に関連付けられた追加の送金を作成しています。
送金オプション
transfer_
文字列には任意の値を指定できますが、1 つのビジネスアクションを示す必要があります。また、関連する支払いや transfer_
の指定がない送金を作成することもできます。これはたとえば、プロバイダーに支払いをする必要があるが、それに関連付けられた顧客の支払いがない場合などです。
注
transfer_
は、関連付けられているオブジェクトのみを識別します。標準の機能は影響を受けません。関連する支払いの資金が利用可能になる前に送金されないようにするには、送金の source_
属性を使用します。
デフォルトでは、金額がプラットフォームのアカウントの利用可能残高を超えていると送金リクエストが失敗します。Stripe は、失敗した送金リクエストを自動的に再試行しません。
支払いに関連付けられている送金の送金リクエストが失敗しないようにします。関連する支払いを送金の source_transaction として指定すると、送金リクエストは自動的に成功します。ただし、Stripe はその支払いの資金がプラットフォームアカウントで利用可能になるまで送金を実行しません。
注
支払いと送金別方式を使用する場合は、入金スケジュールを計画する際に考慮が必要です。自動入金は、source_
が定義されていない送金に支障をきたす場合があります。
実装内容をテストする
実装内容をテストするためのその他の情報については、テストをご覧ください。
売上処理加盟店を指定する
売上処理加盟店は、アカウントに設定されたケイパビリティと支払いの作成方法によって決まります。売上処理加盟店は、支払いの作成に誰の情報を使用するかを決定します。これには、その支払いに使用される顧客のクレジットカードまたは銀行口座の明細に表示される明細書表記 (プラットフォームまたは連結アカウントのもの) が含まれます。
売上処理加盟店を指定することにより、誰に対して支払いを作成するかをより明確にすることができます。たとえば、一部のプラットフォームは最終顧客がプラットフォーム (オンデマンドプラットフォームなど) と直接やり取りすることを理由として、売上処理加盟店となることを希望します。ただし、これと異なり最終顧客と直接やり取りする連結アカウントが存在するプラットフォームもあります (E コマースプラットフォーム上のストアなど)。こうしたシナリオでは、連結アカウントを売上処理加盟店にするのが合理的です。
連結アカウントの ID に on_
パラメーターを設定して、そのアカウントを支払いの売上処理加盟店にすることができます。on_
を使用すると、以下のようになります。
- 連結アカウントの国と売上処理通貨を使用して、支払いが売上として処理されます。
- 連結アカウントの国の手数料体系が使用されます。
- 連結アカウントの明細書表記が顧客のクレジットカード明細書に表示されます。
- 連結アカウントがプラットフォームと異なる国に所在する場合、連結アカウントの住所と電話番号が顧客のクレジットカード明細書に表示されます。
- 入金前の保留中の残高が保持される日数は、連結アカウントの delay_days 設定によって異なります。
on_
が省略された場合、プラットフォームが取引に関する金銭的責任を負います。
注意
on_
パラメーターは、card_payments などの支払いケイパビリティを持つ連結アカウントのみで利用できます。受取人利用規約 が適用されているアカウントは、card_
やその他の支払いケイパビリティをリクエストできません。
手数料を回収する
支払いと送金別方式を使用する場合、プラットフォームは、宛先アカウントに送金する金額を減らすことで、支払いの手数料を回収できます。レストランと運転手への支払いを行うレストランのデリバリーサービス取引の例を考えてください。
- 顧客は 100 USD を支払います。
- Stripe は、3.20 USD の手数料を回収して、残りの 96.80 USD をプラットフォームアカウントの保留中の残高に加算します。
- プラットフォームは、レストランの連結アカウントに 70 USD を送金して、運転手の連結アカウントに 20 USD を送金します。
- 6.80 USD のプラットフォーム手数料がプラットフォームアカウントに残されます。

Connect を使用した複数通貨での支払いの処理について、詳細は複数通貨の処理をご覧ください。
送金可能な金額
デフォルトの動作では、プラットフォームアカウントの利用可能残高から送金が行われます。利用可能残高を超える送金を試行すると、エラーが発生して失敗します。この問題を回避するには、送金を作成するときに source_
パラメーターに支払い ID を指定することで、既存の支払いに関連付けます。source_
を指定すると、関連する支払いがまだ売上処理されていない場合でも、送金リクエストは残高に関係なく成功を返します。ただし、関連する支払いの資金がプラットフォームアカウントの送金に利用できるようになるまで、入金先口座でも資金を利用できません。
注
プラットフォームの残高不足のために送金が失敗した場合、資金を追加しても、失敗したアクションが自動的に再試行されることはありません。資金を追加した後に、失敗した送金または入金を繰り返す必要があります。
元の支払いに transfer_
値が指定されている場合、Stripe は、同じ値を送金の transfer_
に割り当てます。そうでない場合は、Stripe は、group_
と関連する PaymentIntent ID の形式 (例: group_
) で文字列を生成します。この文字列は、支払いと送金の両方の transfer_
として割り当てられます。
注
送金の作成時に source_
を指定する必要があります。この属性は後で更新できません。
PaymentIntent から支払い ID を取得できます。
- PaymentIntent の latest_charge 属性を取得します。この属性は、PaymentIntent に関連付けられた最新の支払いの ID です。
- リクエストで
payment_
を指定して支払いのリストをリクエストします。この方法では、PaymentIntent に関連付けられているすべての支払いの詳細なデータが返されます。intent
このパラメータを使用するときは、以下のことを確認してください。
- 送金金額は、元の支払いの金額を超えることはできません
- 送金の合計が元の支払いを超えない限り、同じ
source_
で複数の送金を作成できますtransaction - 送金により、関連する支払いが保留状態になります。支払いからの売上が N 日後に利用可能になるとすると、送金先 Stripe アカウントが送金から受け取る支払いも N 日後に利用可能になります。
- Stripe は自動的に
transfer_
を作成しますgroup - 支払いに関連付けられている取引残高の通貨は、送金の通貨と同じである必要があります
ACH などの非同期の支払い方法が、後続の送金リクエストの実行後に失敗する場合があります。これらの支払いでは、source_
を使用しないでください。代わりに、charge.succeeded イベントがトリガーされるまで待ち、その後で売上を送金するようにしてください。これらの支払いで source_
を使用する必要がある場合は、支払いの失敗を管理する機能を実装する必要があります。
source_
として使用される支払いが失敗すると、プラットフォームのアカウント残高からの売上が連結アカウントに送金され、支払いを補填します。これらの売上を回収するには、失敗した source_
に関連する送金を差戻しします。
返金する
プラットフォームで作成された支払いは、シークレットキーを使用して返金できます。ただし、支払いの返金は関連するどの送金にも影響しません。以降の送金額の減額、または送金の差戻しによって返金される金額の調整はプラットフォームの責任で行います。
送金を差戻す
Connect は、連結アカウントに対して行われた送金の全額または一部金額 (amount
値で指定) を差戻す機能をサポートしています。送金の差戻しは、支払いに関連する返金や不審請求の申請、または送金のミスの修正のみに使用します。
送金差戻しにより、プラットフォームの利用可能残高に指定された金額 (または全額) が戻されて追加され、それに応じて連結アカウントの利用可能残高が減少します。連結アカウントの利用可能残高が差戻し額よりも大きい場合、または連結されたリザーブが有効になっている場合のみ、送金を差戻すことができます。
送金差戻しに通貨の換算が必要な場合、換算後に差戻し額で残高がゼロになるとエラーが返されます。
連結アカウントの返金を無効にしても、送金の差戻し処理機能はブロックされません。