デスティネーション支払いを作成する
プラットフォームアカウントで支払いを作成し、手数料を回収し、残りの売上を連結アカウントに即時に送金します。
連結アカウントが提供する商品またはサービスについて、顧客がプラットフォームと取引するときに「デスティネーション支払い」を作成し、連結アカウントに売上を即時に送金します。この支払いタイプの特徴は以下のとおりです。
- プラットフォームのアカウントで支払いを作成します。
- 売上の一部または全額を、連結アカウントに送金するかどうかを決定します。
- Stripe の手数料、返金、チャージバックは、お客様のアカウント残高から引き落とされます。
この支払いタイプは、住宅賃貸マーケットプレイスの Airbnb や、ライドシェアアプリの Lyft などのマーケットプレイスに最適です。
特定の例外を除き、プラットフォームと連結アカウントが同じ地域にない場合は、Payment Intent で on_behalf_of パラメーターを使用して、連結アカウントを売上処理加盟店として指定する必要があります。
Stripe ダッシュボードの全機能を利用できない連結アカウントの場合には、デスティネーション支払いを使用することをお勧めします。
Stripe Elements を使用して、サイトに UI コンポーネントを埋め込むことでカスタムの決済システムを構築します。クライアント側とサーバー側のコードでさまざまな支払い方法を受け付ける決済フォームを構築します。この実装と、Stripe のその他の実装タイプとの比較をご覧ください。
まず、Stripe アカウントを登録します。
アプリケーションから Stripe API にアクセスするには、Stripe の公式ライブラリを使用します。
PaymentIntent を作成するサーバー側
Stripe は PaymentIntent (支払いインテント) オブジェクトを使用して、顧客から支払いを回収する意図を示し、プロセス全体を通して請求の実施と支払い状態の変化を追跡します。
購入プロセスで顧客に表示される支払い方法は、PaymentIntent にも含まれています。Stripe によってダッシュボードの設定から支払い方法を自動的に取得することも、手動でリスト化することもできます。
貴社の構築済みのシステムで支払い方法の提供にコードベースのオプションを必要とする場合を除き、支払い方法を手動でリスト化しないでください。Stripe は通貨、支払い方法の制約、その他のパラメーターを評価し、対応可能な支払い方法のリストを決定します。購入完了率の上昇につながり、使用通貨と顧客の所在地に最も適した支払い方法を優先的に表示します。一方、優先度の低い支払い方法は、オーバーフローメニューに隠された状態になります。
client secret を取得する
PaymentIntent には、client secret が含まれています。これは、支払いプロセスを安全に完了するためにクライアント側で使用されます。client secret をクライアント側に渡す際は、いくつかの方法を使用できます。
支払いの詳細を収集するクライアント側
Payment Element を使用してクライアント側で支払い詳細を収集します。Payment Element は事前構築された UI コンポーネントであり、さまざまな決済手段の詳細の収集をシンプルにします。
Payment Element には、HTTPS 接続を介して支払い情報を Stripe に安全に送信する iframe が含まれています。一部の支払い方法では、支払いを確定するために別のページにリダイレクトする必要があるため、Payment Element を別の iframe 内に配置しないでください。
iframe の使用を選択し、Apple Pay または Google Pay を受け付ける場合、iframe の allow 属性が "payment *"
に設定されている必要があります。
構築済みのシステムを機能させるには、決済ページのアドレスの先頭を http://
ではなく https://
にする必要があります。HTTPS を使用しなくてもシステムをテストできますが、本番環境で決済を受け付ける準備が整ったら、必ず、HTTPS を有効にしてください。
Payment Element によって動的なフォームが表示され、顧客はここで支払い方法を選択できます。支払い方法ごとに、フォームでは、必要な支払いの詳細のすべてを入力するように顧客に自動的に求めます。
デザインをカスタマイズする
Elements
プロバイダーを作成する際に、Appearance (デザイン) オブジェクトを options
に渡すことで、サイトのデザインに合わせて Payment Element をカスタマイズできます。
住所を収集
デフォルトでは、Payment Element は必要な請求先住所情報のみを収集します。(たとえば、デジタル商品およびサービスの税金を計算するなどの目的で) 顧客の詳細な請求先住所または配送先住所を収集するには、Address Element を使用します。
Apple Pay マーチャントトークンをリクエストする
Apple Pay の決済を受け付けるよう自社のシステムを構築している場合、マーチャントトークンを返すように Apple Pay インターフェイスを設定して、加盟店が開始する取引 (MIT) を有効にすることをお勧めします。Payment Element で関連するマーチャントトークンのタイプをリクエストします。
Stripe に支払いを送信するクライアント側
Payment Element からの詳細を指定して stripe.confirmPayment を使用し、支払いを完了します。ユーザーが支払いを完了した後に Stripe がユーザーをリダイレクトする場所を指定するには、この関数に return_url を指定します。ユーザーはまず、銀行のオーソリページなどの中間サイトにリダイレクトされ、その後 return_
にリダイレクトされます。カード支払いでは、支払いが正常に完了するとすぐに return_
にリダイレクトします。
カード決済で支払いの完了後にリダイレクトを行わない場合は、redirect に if_
を設定できます。これで、リダイレクトベースの決済手段で購入する顧客のみがリダイレクトされます。
return_
が、Web サイト上の支払いステータスを表示するページと対応していることを確認します。Stripe が顧客を return_
にリダイレクトするときは、以下の URL クエリーパラメーターが指定されます。
パラメーター | 説明 |
---|---|
payment_ | PaymentIntent の一意の識別子。 |
payment_ | PaymentIntent オブジェクトの client secret。 |
注意
顧客のブラウザーセッションを追跡するツールを利用している場合、リファラー除外リストに stripe.
ドメインの追加が必要になる場合があります。リダイレクトを行うと、一部のツールでは新しいセッションが作成され、セッション全体の追跡ができなくなります。
クエリパラメーターのいずれか 1 つを使用して PaymentIntent を取得します。PaymentIntent のステータスを調べて、顧客に表示する内容を決定します。また、return_
を指定するときにカスタムのクエリパラメーターを追加することもできます。このパラメーターはリダイレクトプロセスの間維持されます。
支払い後のイベントを処理するサーバー側
支払いが完了すると、Stripe は payment_intent.succeeded イベントを送信します。ダッシュボードの Webhook ツールを使用するか Webhook のガイドに従ってこれらのイベントを受信し、顧客への注文確認メールの送信、データベースでの売上の記録、配送ワークフローの開始などのアクションを実行します。
クライアントからのコールバックを待つのではなく、これらのイベントをリッスンします。クライアントでは、コールバックが実行される前に顧客がブラウザーのウィンドウを閉じたり、アプリを終了する場合、また悪意を持つクライアントがレスポンスを不正操作する場合もあります。非同期型のイベントをリッスンするよう組み込みを設定すると、単一の組み込みで複数の異なるタイプの支払い方法を受け付けることができます。
Payment Element を使用して支払いを回収する場合は、payment_
イベントのほかにこれらのイベントを処理することをお勧めします。
イベント | 説明 | アクション |
---|---|---|
payment_intent.succeeded | 顧客が正常に支払いを完了したときに送信されます。 | 顧客に注文の確定を送信し、顧客の注文のフルフィルメントを実行します。 |
payment_intent.processing | 顧客が正常に支払いを開始したが、支払いがまだ完了していない場合に送信されます。このイベントは、多くの場合、顧客が口座引き落としを開始するときに送信されます。その後、payment_ イベント、また、失敗の場合は payment_ イベントが送信されます。 | 顧客に注文確認メールを送信し、支払いが保留中であることを示します。デジタル商品では、支払いの完了を待たずに注文のフルフィルメントを行うことが必要になる場合があります。 |
payment_intent.payment_failed | 顧客が支払いを試みたが、支払いに失敗する場合に送信されます。 | 支払いが processing から payment_ に変わった場合は、顧客に再度支払いを試すように促します。 |
実装内容をテストする
実装内容をテストするためのその他の情報については、テストをご覧ください。
手数料を回収する
支払いが処理される際に、取引の全額を連結アカウントに送金するのではなく、プラットフォームが取引金額の一部を手数料という形で受け取ることを決定できます。手数料の料金体系は、次の 2 つの方法で設定できます。
プラットフォームの料金設定ツールを使用して、プラットフォーム手数料の料金体系ルールを設定してテストします。この Stripe ダッシュボードのノーコード機能は、現時点では Stripe 手数料の支払い責任を負うプラットフォームでのみ利用できます。
社内で料金体系ルールを設定し、application_fee_amount または transfer_data[amount] パラメーターを使用して、PaymentIntent で直接手数料を指定します。この方法で設定された手数料は、プラットフォーム料金設定ツールで指定された料金体系ロジックを上書きします。
売上処理加盟店を指定する
売上処理加盟店は、アカウントに設定されたケイパビリティと支払いの作成方法によって決まります。売上処理加盟店は、支払いの作成に誰の情報を使用するかを決定します。これには、その支払いに使用される顧客のクレジットカードまたは銀行口座の明細に表示される明細書表記 (プラットフォームまたは連結アカウントのもの) が含まれます。
売上処理加盟店を指定することにより、誰に対して支払いを作成するかをより明確にすることができます。たとえば、一部のプラットフォームは最終顧客がプラットフォーム (オンデマンドプラットフォームなど) と直接やり取りすることを理由として、売上処理加盟店となることを希望します。ただし、これと異なり最終顧客と直接やり取りする連結アカウントが存在するプラットフォームもあります (E コマースプラットフォーム上のストアなど)。こうしたシナリオでは、連結アカウントを売上処理加盟店にするのが合理的です。
連結アカウントの ID に on_
パラメーターを設定して、そのアカウントを支払いの売上処理加盟店にすることができます。on_
を使用すると、以下のようになります。
- 連結アカウントの国と売上処理通貨を使用して、支払いが売上として処理されます。
- 連結アカウントの国の手数料体系が使用されます。
- 連結アカウントの明細書表記が顧客のクレジットカード明細書に表示されます。
- 連結アカウントがプラットフォームと異なる国に所在する場合、連結アカウントの住所と電話番号が顧客のクレジットカード明細書に表示されます。
- 入金前の保留中の残高が保持される日数は、連結アカウントの delay_days 設定によって異なります。
on_
が省略された場合、プラットフォームが取引に関する金銭的責任を負います。
注意
on_
パラメーターは、card_payments などの支払いケイパビリティを持つ連結アカウントのみで利用できます。受取人利用規約 が適用されているアカウントは、card_
やその他の支払いケイパビリティをリクエストできません。
返金する
Payment Intents API を使用している場合、返金は最も最近に作成された支払いに対して発行する必要があります。
プラットフォームアカウントで作成された支払いは、プラットフォームアカウントのシークレットキーを使用して返金できます。transfer_
が設定された支払いを返金する場合、デフォルトではデスティネーションアカウントがそこに送金された売上を保持し、プラットフォームアカウントがその返金からマイナスの残高をカバーします。その返金をカバーするために連結アカウントから売上を取り戻すには、返金を作成する際に reverse_
パラメータを true
に設定します。
デフォルトでは支払い額すべてが返金されますが、amount
値を正の整数に設定することで、一部返金を作成することができます。
その払い戻しによって支払い額全額が返金される場合、送金額全額が差し戻しされます。それ以外の場合には、送金額の比例配分された部分が差し戻しされます。
プラットフォーム手数料を返金する
プラットフォーム手数料が含まれる支払いを返金すると、デフォルトではプラットフォームアカウントがプラットフォーム手数料の売上を確保します。プラットフォーム手数料の売上を連結アカウントに戻すには、返金を作成する際に refund_application_fee パラメーターに true
を設定します。
デスティネーション支払いのプラットフォーム手数料を返金する場合には、送金も差し戻す必要があることに注意します。その返金によって支払い額全額が返金される場合、プラットフォーム手数料の全額も払い戻されます。それ以外の場合には、プラットフォーム手数料の比例配分された部分が返金されます。
別の方法として、false 値の refund_
を指定し、API を通じてプラットフォーム手数料を別途返金することもできます。
失敗した返金
返金が失敗した場合、またはキャンセルした場合、失敗した返金額はプラットフォームアカウントの Stripe 残高に戻されます。必要に応じて、送金を作成して、資金を連結アカウントに移動します。
不審請求の申請を処理する
デスティネーション支払いでは、on_
の有無にかかわらず、プラットフォームアカウントから不審請求の申請に係る金額と手数料が引き落とされます。
不審請求の申し立て作成イベントをリッスンするために、Webhook を設定することをお勧めします。このような状況が発生した場合は、ダッシュボードから送金を差戻すか、送金の差戻しを作成して、連結アカウントから売上の回収を試みることができます。
連結アカウントの残高がマイナスの場合、debit_
が true
に設定されていれば、Stripe はその外部口座からの引き落としを試みます。
不審請求の申し立てに反論して主張が認められた場合は、以前に差戻した売上を連結アカウントに送金できます。プラットフォームの残高が不足している場合、送金は失敗します。Stripe 残高に資金を追加して、残高不足によるエラーを防止してください。
よくある間違い
以前差戻した売上を再送金する場合、海外送金に関する制限の対象となるため、連結アカウントに返済する方法がなくなる可能性があります。その場合は代わりに、不審請求の申し立てがなくなるまで、on_
を指定したデスティネーション支払いで、不審請求の申し立てが行われた海外への支払い送金が回復されるのを待ちます。
Connect の埋め込みコンポーネント
デスティネーション支払いは Connect 埋め込みコンポーネント でサポートされています。決済埋め込みコンポーネント を使用することで、連結アカウントがサイト内から決済情報を表示できるようになります。on_
を含むデスティネーション支払いの場合、destination_on_behalf_of_charge_management 機能を使用して、連結アカウントが追加の詳細情報を表示し、返金や不審請求の申し立てを管理し、決済をキャプチャーできるようにすることができます。
以下のコンポーネントには、デスティネーション支払いの情報が表示されます。
支払いコンポーネント:アカウントのすべての支払いと紛争を表示します。
決済の詳細:アカウントのすべての決済と不審請求の申し立てを表示します。
紛争一覧コンポーネント:アカウントのすべての紛争を表示します。
支払いに関する紛争コンポーネント:特定の支払いに関する紛争を表示します。これを使って、支払い用 UI があるページに紛争管理機能を組み込むことができます。