支払いと送金別方式を作成する

プラットフォームアカウントで支払いを作成し、複数の連結アカウントに売上を送金できます。

1 回の支払いから複数の連結アカウントに、または支払い時に特定のユーザーが不明な場合に売上を送金するには、「支払いと送金別方式」を作成します。プラットフォームアカウントでの支払いは、連結アカウントへの送金から切り離されます。この支払いタイプの特徴は以下のとおりです。

プラットフォームのアカウントで支払いを作成し、売上を連結アカウントに送金します。この支払いは、ご自身のアカウントでの支払いとして表示され、さらに連結アカウントへの送金も表示されます (金額はご自身で決定します)。この金額はアカウント残高から引き落とされます。
複数の連結アカウントに売上を送金できます。
Stripe の手数料、返金、チャージバックは、お客様のアカウント残高から引き落とされます。

この支払いタイプは、レストランのデリバリープラットフォームである DoorDash のように、複数の当事者間で支払いを分割する必要があるマーケットプレイスに最適です。

Stripe は、以下の地域で支払いと送金別方式に対応しています。

アイルランド

アメリカ

イギリス

イタリア

エストニア

オーストラリア

オーストリア

オランダ

カナダ

キプロス

ギリシャ

クロアチア

シンガポール

スイス

スウェーデン

スペイン

スロバキア

スロベニア

チェコ共和国

デンマーク

ドイツ

ニュージーランド

ノルウェー

ハンガリー

フィンランド

ブラジル

フランス

ブルガリア

ベルギー

ポーランド

ポルトガル

マルタ

マレーシア

メキシコ

ラトビア

リトアニア

リヒテンシュタイン

ルーマニア

ルクセンブルグ

日本

多くのシナリオでは、プラットフォームと連結アカウントは同じ地域に所在している必要があります。許可されていない国境を越えて送金しようとすると、エラーが返されます。複数地域にわたる場合のサポートについては、海外送金をご覧ください。送金は、支払い、トップアップ、および手数料の許可されたユースケースと併用する場合にのみ使用する必要があります。

注

Express ダッシュボードにアクセスできる連結アカウント、またはダッシュボードにアクセスできない連結アカウントには、支払いと送金別方式を使用することをお勧めします。

ウェブ

iOS

Android

React Native

Redirect to a Stripe-hosted payment page using Stripe Checkout. See how this integration compares to Stripe’s other integration types.

導入作業

ローコード

接続方法のタイプ

Stripe がオンラインで提供する決済ページにリダイレクトする

UI のカスタマイズ

限定的なカスタマイズ

試してみる

まず、Stripe アカウントを登録します。

アプリケーションから Stripe API にアクセスするには、Stripe の公式ライブラリを使用します。

Checkout セッションを作成する
クライアント側
サーバー側

Checkout Session (Checkout セッション) は、ラインアイテム、注文金額と通貨、および受け付け可能な支払い方法など、支払いフォームで顧客に表示される内容を制御します。サーバー側のエンドポイントを呼び出して、Checkout セッションを作成する購入ボタンをウェブサイトに追加します。

checkout.html
<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_items: この属性は、顧客が購入しようとしているアイテムを表します。このアイテムは Stripe がオンラインで提供する購入ページに表示されます。
payment_intent_data[transfer_group]: 一意の文字列を transfer_group として使用し、相互に関連付けるオブジェクトを識別します。Stripe は、transfer_group 値を指定して PaymentIntent の支払いを自動的に作成する際、同じ値を支払いの transfer_group に割り当てます。
success_url: Stripe は、顧客が支払いを完了した後に成功時の URL にリダイレクトし、{CHECKOUT_SESSION_ID} の文字列を Checkout セッションの ID に置き換えます。この ID を使用して Checkout セッションを取得し、ステータスを確認して、顧客に表示する内容を決定してください。自社で使用するクエリパラメーターを追加することもできます。このパラメーターはリダイレクトプロセス全体にわたって存続します。詳細については、Stripe がオンラインで提供するページでリダイレクトの動作をカスタマイズするをご覧ください。

支払い後のイベントを処理する
サーバー側

支払いが完了すると 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_group を指定することで、アカウントから連結アカウントに送金します。

送金額と支払い金額が一致している必要はありません。1 回の支払いを複数の送金に分割したり、複数の支払いを 1 回の送金に含めることができます。以下の例では、同じ transfer_group に関連付けられた追加の送金を作成しています。

送金オプション

transfer_group 文字列には任意の値を指定できますが、1 つのビジネスアクションを示す必要があります。また、関連する支払いや transfer_group の指定がない送金を作成することもできます。これはたとえば、プロバイダーに支払いをする必要があるが、それに関連付けられた顧客の支払いがない場合などです。

注

transfer_group は、関連付けられているオブジェクトのみを識別します。標準の機能は影響を受けません。関連する支払いの資金が利用可能になる前に送金されないようにするには、送金の source_transaction 属性を使用します。

By default, a transfer request fails when the amount exceeds the platform’s available account balance. Stripe doesn’t automatically retry failed transfer requests.

You can avoid failed transfer requests for transfers that are associated with charges. When you specify the associated charge as the transfer’s source_transaction, the transfer request automatically succeeds. However, we don’t execute the transfer until the funds from that charge are available in the platform account.

注

支払いと送金別方式を使用する場合は、入金スケジュールを計画する際に考慮が必要です。自動入金は、source_transaction が定義されていない送金に支障をきたす場合があります。

実装内容をテストする

カード番号	シナリオ	テスト方法
	カード支払いは成功し、認証は必要とされません。	クレジットカード番号と、任意の有効期限、セキュリティコード、郵便番号を使用してクレジットカードフォームに入力します。
	カード支払いには認証が必要です。	クレジットカード番号と、任意の有効期限、セキュリティコード、郵便番号を使用してクレジットカードフォームに入力します。
	カードは、`insufficient_funds` などの拒否コードで拒否されます。	クレジットカード番号と、任意の有効期限、セキュリティコード、郵便番号を使用してクレジットカードフォームに入力します。
	UnionPay カードは、13 ～ 19 桁の可変長です。	クレジットカード番号と、任意の有効期限、セキュリティコード、郵便番号を使用してクレジットカードフォームに入力します。

実装内容をテストするためのその他の情報については、テストをご覧ください。

オプションその他の支払い方法を有効にする

売上処理加盟店を指定する

売上処理加盟店は、アカウントに設定されたケイパビリティと支払いの作成方法によって決まります。売上処理加盟店は、支払いの作成に誰の情報を使用するかを決定します。これには、その支払いに使用される顧客のクレジットカードまたは銀行口座の明細に表示される明細書表記 (プラットフォームまたは連結アカウントのもの) が含まれます。

売上処理加盟店を指定することにより、誰に対して支払いを作成するかをより明確にすることができます。たとえば、一部のプラットフォームは最終顧客がプラットフォーム (オンデマンドプラットフォームなど) と直接やり取りすることを理由として、売上処理加盟店となることを希望します。ただし、これと異なり最終顧客と直接やり取りする連結アカウントが存在するプラットフォームもあります (E コマースプラットフォーム上のストアなど)。こうしたシナリオでは、連結アカウントを売上処理加盟店にするのが合理的です。

連結アカウントの ID に on_behalf_of パラメーターを設定して、そのアカウントを支払いの売上処理加盟店にすることができます。on_behalf_of を使用すると、以下のようになります。

連結アカウントの国と売上処理通貨を使用して、支払いが売上として処理されます。
連結アカウントの国の手数料体系が使用されます。
連結アカウントの明細書表記が顧客のクレジットカード明細書に表示されます。
連結アカウントがプラットフォームと異なる国に所在する場合、連結アカウントの住所と電話番号が顧客のクレジットカード明細書に表示されます。
入金前の保留中の残高が保持される日数は、連結アカウントの delay_days 設定によって異なります。

on_behalf_of が省略された場合、プラットフォームが取引に関する金銭的責任を負います。

注意

on_behalf_of パラメーターは、card_payments などの支払いケイパビリティを持つ連結アカウントのみで利用できます。受取人利用規約が適用されているアカウントは、card_payments やその他の支払いケイパビリティをリクエストできません。

手数料を回収する

支払いと送金別方式を使用する場合、プラットフォームは、宛先アカウントに送金する金額を減らすことで、支払いの手数料を回収できます。レストランと運転手への支払いを行うレストランのデリバリーサービス取引の例を考えてください。

顧客は 100 USD を支払います。
Stripe は、3.20 USD の手数料を回収して、残りの 96.80 USD をプラットフォームアカウントの保留中の残高に加算します。
プラットフォームは、レストランの連結アカウントに 70 USD を送金して、運転手の連結アカウントに 20 USD を送金します。
6.80 USD のプラットフォーム手数料がプラットフォームアカウントに残されます。

支払いがプラットフォームアカウントの手数料と連結アカウントへの送金に分割される仕組み

Connect を使用した複数通貨での支払いの処理について、詳細は複数通貨の処理をご覧ください。

送金可能な金額

デフォルトの動作では、プラットフォームアカウントの利用可能な残高から売上を送金します。利用可能な残高を超えて送金しようとすると、エラーが発生します。この問題を回避するには、送金を作成するときに、source_transaction パラメーターとして支払い ID を指定して、その送金を既存の支払いに関連付けます。source_transaction を指定すると、関連する支払いがまだ売上処理されていない場合でも、利用可能な残高に関係なく、送金リクエストは成功を返します。ただし、関連付けられた支払いによる売上をプラットフォームアカウントからの送金に利用できるようになるまで、売上は入金先アカウントで利用できません。

注

プラットフォームの残高不足のために送金が失敗した場合、資金を追加しても、失敗したアクションが自動的に再試行されることはありません。資金を追加した後に、失敗した送金または入金を繰り返す必要があります。

元の支払いに transfer_group 値が指定されている場合、Stripe は、同じ値を送金の transfer_group に割り当てます。そうでない場合は、Stripe は、group_ と関連する PaymentIntent ID の形式 (例: group_pi_2NHDDD589O8KAxCG0179Du2s) で文字列を生成します。この文字列は、支払いと送金の両方の transfer_groupとして割り当てられます。

注

送金の作成時に source_transaction を指定する必要があります。この属性は後で更新できません。

PaymentIntent から支払い ID を取得できます。

PaymentIntent の latest_charge 属性を取得します。この属性は、PaymentIntent に関連付けられた最新の支払いの ID です。
リクエストで payment_intent を指定して支払いのリストをリクエストします。この方法では、PaymentIntent に関連付けられているすべての支払いの詳細なデータが返されます。

このパラメータを使用するときは、以下のことを確認してください。

送金金額は、元の支払いの金額を超えることはできません
送金の合計が元の支払いを超えない限り、同じ source_transaction で複数の送金を作成できます
送金により、関連する支払いが保留状態になります。支払いからの売上が N 日後に利用可能になるとすると、送金先 Stripe アカウントが送金から受け取る支払いも N 日後に利用可能になります。
Stripe は自動的に transfer_group を作成します
支払いに関連付けられている取引残高の通貨は、送金の通貨と同じである必要があります

ACH などの非同期の支払い方法が、後続の送金リクエストの実行後に失敗する場合があります。これらの支払いでは、source_transaction を使用しないでください。代わりに、charge.succeeded イベントがトリガーされるまで待ち、その後で売上を送金するようにしてください。これらの支払いで source_transaction を使用する必要がある場合は、支払いの失敗を管理する機能を実装する必要があります。

source_transaction として使用される支払いが失敗すると、プラットフォームのアカウント残高からの売上が連結アカウントに送金され、支払いを補填します。これらの売上を回収するには、失敗した source_transaction に関連する送金を差戻しします。

返金する

プラットフォームで作成された支払いは、シークレットキーを使用して返金できます。ただし、支払いの返金は関連するどの送金にも影響しません。以降の送金額の減額、または送金の差戻しによって返金される金額の調整はプラットフォームの責任で行います。

送金を差戻す

Connect は、連結アカウントに対して行われた送金の全額または一部金額 (amount 値で指定) を差戻す機能をサポートしています。送金の差戻しは、支払いに関連する返金や不審請求の申請、または送金のミスの修正のみに使用します。

送金差戻しにより、プラットフォームの利用可能残高に指定された金額 (または全額) が戻されて追加され、それに応じて連結アカウントの利用可能残高が減少します。連結アカウントの利用可能残高が差戻し額よりも大きい場合、または連結されたリザーブが有効になっている場合のみ、送金を差戻すことができます。

送金差戻しに通貨の換算が必要な場合、換算後に差戻し額で残高がゼロになるとエラーが返されます。

連結アカウントの返金を無効にしても、送金の差戻し処理機能はブロックされません。

注