デスティネーション支払いを作成する

プラットフォームアカウントで支払いを作成し、手数料を回収し、残りの売上を連結アカウントに即時に送金します。

連結アカウントが提供する商品またはサービスについて、顧客がプラットフォームと取引するときに「デスティネーション支払い」を作成し、連結アカウントに売上を即時に送金します。この支払いタイプの特徴は以下のとおりです。

プラットフォームのアカウントで支払いを作成します。
売上の一部または全額を、連結アカウントに送金するかどうかを決定します。
Stripe の手数料、返金、チャージバックは、お客様のアカウント残高から引き落とされます。

この支払いタイプは、住宅賃貸マーケットプレイスの Airbnb や、ライドシェアアプリの Lyft などのマーケットプレイスに最適です。

特定の例外を除き、プラットフォームと連結アカウントが同じ地域にない場合は、Payment Intent で on_behalf_of パラメーターを使用して、連結アカウントを売上処理加盟店として指定する必要があります。

プライベートプレビュー

on_behalf_of パラメーターを使用せずにリージョン間のデスティネーション支払いを使用する機能は、プライベートプレビュー版でのみ以下のシナリオにご利用いただけます。

プラットフォームがイギリスまたは EU にあり、連結アカウントがアメリカにあります。
プラットフォームがアメリカにあり、連結アカウントがイギリスまたは EU にあります。

アクセスをリクエストするには、お問い合わせください。

Stripe ダッシュボードの全機能を利用できない連結アカウントの場合には、デスティネーション支払いを使用することをお勧めします。

ウェブ

iOS

Android

React Native

Stripe Checkout を使用して、Stripe がオンラインで提供する決済ページにリダイレクトします。この実装と、Stripe の他の実装タイプとの比較をご覧ください。

導入作業

ローコード

接続方法のタイプ

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 に顧客をリダイレクトします。

payment_intent_data[transfer_data][destination]: このパラメーターは、支払いがデスティネーション支払いであることを示しています。デスティネーション支払いでは、支払いがプラットフォームで処理され、売上が即時かつ自動的に連結アカウントの保留中の残高に送金されます。
line_items: このパラメーターは、顧客が購入しようとしているアイテムを表します。このアイテムはオンライン決済フォームに表示されます。
success_url: Stripe は、顧客が支払いを完了した後に成功時の URL にリダイレクトし、{CHECKOUT_SESSION_ID} の文字列を Checkout セッションの ID に置き換えます。この ID を使用して Checkout セッションを取得し、ステータスを確認して、顧客に表示する内容を決定してください。自社で使用するクエリパラメーターを追加することもできます。このパラメーターはリダイレクトプロセス全体にわたって存続します。詳細については、Stripe がオンラインで提供するページでリダイレクトの動作をカスタマイズするをご覧ください。
payment_intent_data[application_fee_amount]: このパラメーターは、プラットフォームが取引で受け取る予定の金額を指定します。支払いがキャプチャーされると、プラットフォームから、transfer_data[destination] で指定された連結アカウントに支払い金額の全額が即時送金されます。その後 application_fee_amount がプラットフォームに返金され、プラットフォームの金額から Stripe 手数料が差し引かれます。

デスティネーション支払いを処理する場合、Checkout ではプラットフォームアカウントのブランド設定を使用します。詳細については、ブランディングをカスタマイズするをご覧ください。

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

支払いが完了すると 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 または失敗のステータスに変わります。

実装内容をテストする

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

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

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

手数料を回収する

支払いが処理される際に、取引の全額を連結アカウントに送金するのではなく、プラットフォームが取引金額の一部を手数料という形で受け取ることを決定できます。手数料の料金体系は、次の 2 つの方法で設定できます。

プラットフォームの料金設定ツールを使用して、プラットフォーム手数料の料金体系ルールを設定してテストします。この Stripe ダッシュボードのノーコード機能は、現時点では Stripe 手数料の支払い責任を負うプラットフォームでのみ利用できます。
社内で料金体系ルールを設定し、application_fee_amount または transfer_data[amount] パラメーターを使用して、PaymentIntent で直接手数料を指定します。この方法で設定された手数料は、プラットフォーム料金設定ツールで指定された料金体系ロジックを上書きします。

application_fee_amount を指定して支払いを作成すると、支払いのキャプチャー後に、支払いの総額が即座にプラットフォームから transfer_data[destination] アカウントに送金されます。その後、application_fee_amount (上限は支払い総額) がプラットフォームに送金されます。

プラットフォーム手数料が回収されると、Application Fee (プラットフォーム手数料) オブジェクトが作成されます。プラットフォーム手数料のリストは、ダッシュボード、プラットフォーム手数料、または Sigma で確認できます。プラットフォーム手数料オブジェクトの amount プロパティを使用して、項目別の手数料レポートを作成することもできます。

application_fee_amount を使用する際には、以下の点に留意します。

application_fee_amount は合計取引額が上限です。
application_fee_amount は常に取引と同じ通貨で計算されます。
プラットフォーム手数料は、連結アカウントの売上処理通貨と同じ通貨で売上として処理されます。越境デスティネーション支払いの場合は、プラットフォームの売上処理通貨と異なる通貨になる場合があります。
application_fee_amount がお客様のアカウントに送金された後に、お客様のプラットフォームが Stripe 手数料を支払います。
金額には追加の Stripe 手数料は適用されません。
プラットフォームは埋め込みのプラットフォーム手数料レポートを使用して、回収した手数料を照合できます。
Stripe がオンラインで提供するダッシュボードや、支払い詳細コンポーネントなどのコンポーネントでは、連結アカウントは合計金額とプラットフォーム手数料のどちらの金額も表示できます。

売上のフロー

上記のコードでは、支払いの全額 (10.00 USD) が連結アカウントの保留残高に追加されます。application_fee_amount (1.23 USD) はその支払い金額から差し引かれ、お客様のプラットフォームに送金されます。次に Stripe 手数料 (0.59 USD) がプラットフォームアカウントの残高から差し引かれます。プラットフォーム手数料から Stripe 手数料を差し引いた金額 (1.23 USD - 0.59 USD = 0.64 USD) は、プラットフォームアカウントの残高に残ります。

通常の Stripe 支払いからの売上と同様に、プラットフォームアカウントの通常の送金スケジュールで application_fee_amount が利用可能になります。

ブランディングをカスタマイズする

プラットフォームは、ダッシュボードのブランディング設定を使用して、支払いページのブランディングをカスタマイズできます。デスティネーション支払いの場合、Checkout はプラットフォームアカウントのブランド設定を使用します。on_behalf_of を使用したデスティネーション支払いの場合、Checkout は連結アカウントのブランド設定を使用します。

プラットフォームは、Update Account API を使用して、連結アカウントのブランディング設定を行うことができます。

icon: Checkout ページのヘッダーにあるビジネス名の横に表示されます。
logo: Checkout ページのヘッダーで、アイコンとビジネス名の代わりに使用されます。
primary_color: Checkout ページの背景色として使用されます。
secondary_color: Checkout ページのボタンの色として使用されます。

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

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

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

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

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

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

注意

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

返金する

Payment Intents API を使用している場合、返金は最も最近に作成された支払いに対して発行する必要があります。

プラットフォームアカウントで作成された支払いは、プラットフォームアカウントのシークレットキーを使用して返金できます。transfer_data[destination] が設定された支払いを返金する場合、デフォルトではデスティネーションアカウントがそこに送金された売上を保持し、プラットフォームアカウントがその返金からマイナスの残高をカバーします。その返金をカバーするために連結アカウントから売上を取り戻すには、返金を作成する際に reverse_transfer パラメータを true に設定します。

デフォルトでは支払い額すべてが返金されますが、amount 値を正の整数に設定することで、一部返金を作成することができます。

その払い戻しによって支払い額全額が返金される場合、送金額全額が差し戻しされます。それ以外の場合には、送金額の比例配分された部分が差し戻しされます。

プラットフォーム手数料を返金する

プラットフォーム手数料が含まれる支払いを返金すると、デフォルトではプラットフォームアカウントがプラットフォーム手数料の売上を確保します。プラットフォーム手数料の売上を連結アカウントに戻すには、返金を作成する際に refund_application_fee パラメーターに true を設定します。

デスティネーション支払いのプラットフォーム手数料を返金する場合には、送金も差し戻す必要があることに注意します。その返金によって支払い額全額が返金される場合、プラットフォーム手数料の全額も払い戻されます。それ以外の場合には、プラットフォーム手数料の比例配分された部分が返金されます。

別の方法として、false 値の refund_application_fee を指定し、API を通じてプラットフォーム手数料を別途返金することもできます。

失敗した返金

返金が失敗した場合、またはキャンセルした場合、失敗した返金額はプラットフォームアカウントの Stripe 残高に戻されます。必要に応じて、送金を作成して、資金を連結アカウントに移動します。

不審請求の申請を処理する

デスティネーション支払いでは、on_behalf_of の有無にかかわらず、プラットフォームアカウントから不審請求の申請に係る金額と手数料が引き落とされます。

不審請求の申し立て作成イベントをリッスンするために、Webhook を設定することをお勧めします。このような状況が発生した場合は、ダッシュボードから送金を差戻すか、送金の差戻しを作成して、連結アカウントから売上の回収を試みることができます。

連結アカウントの残高がマイナスの場合、debit_negative_balances が true に設定されていれば、Stripe はその外部口座からの引き落としを試みます。

不審請求の申し立てに反論して主張が認められた場合は、以前に差戻した売上を連結アカウントに送金できます。プラットフォームの残高が不足している場合、送金は失敗します。Stripe 残高に資金を追加して、残高不足によるエラーを防止してください。

よくある間違い

以前差戻した売上を再送金する場合、海外送金に関する制限の対象となるため、連結アカウントに返済する方法がなくなる可能性があります。その場合は代わりに、不審請求の申し立てがなくなるまで、on_behalf_of を指定したデスティネーション支払いで、不審請求の申し立てが行われた海外への支払い送金が回復されるのを待ちます。

注