オンラインマーケットプレイスは、世界の EC の大きな割合を占めており、数億人の顧客と個々の売り手を結び付けています。マーケットプレイスを運営するには、資金の流れを適切に管理する必要があります。つまり、買い手が決済し、売り手が代金を受け取り、プラットフォームがその一部を手数料として受け取るということです。これらすべてを、運営するあらゆる地域のすべての取引と売り手にわたって正確に実行しなければなりません。マーケットプレイス向け決済処理のための API は、これを可能にするインフラの一部です。

以下では、マーケットプレイス向け決済 API の仕組み、複数当事者間取引をどのように処理するか、またプラットフォーム向けに選ぶ際に確認すべきポイントを説明します。

主なポイント

• マーケットプレイス向け決済 API は、送金、手数料の回収、入金を含む資金移動のライフサイクル全体を管理します。

• 標準の決済 API とは異なり、マーケットプレイス API は、複数当事者間取引、分割決済、アカウント単位で設定可能な入金タイミングを管理できるように構築されています。

• 決済方式、顧客確認 (KYC) への対応、不審請求の申請管理に関する判断は、プラットフォームが本番稼働すると差し戻すのが困難です。

マーケットプレイス向け決済処理 API とは

API は、あるソフトウェアが別のソフトウェアの機能を利用できるようにするルールやプロトコルの集合です。マーケットプレイス向け決済処理 API を使うと、プラットフォームは 1 つの統合されたフローの中で、買い手から資金を受け取り、それを売り手や代行業者に分配し、自社の手数料を収集できます。

マーケットプレイス決済 API の仕組み

マーケットプレイス向け決済 API は、プラットフォームと資金移動を管理する金融システムの間に位置します。買い手が購入を完了すると、API は次のアクションを実行できるようにします。

• 決済の確定: 買い手のカードまたは銀行口座に請求が行われます。API は認証、オーソリゼーション、資金の確定を管理します。

• 手数料の計算: プラットフォームの手数料が計算され、資金が売り手に移動する前に差し引かれます。

• 送金: 残額は、即時または予定された入金ベースで、適切な売り手のアカウントに送られます。

• 入金の実行: 売り手は、プラットフォームの入金スケジュールに従って、銀行口座に資金を受け取ります。

最初の決済イベントが発生すると、API が一連の処理全体をプログラムで実行します。

マーケットプレイス向け決済 API による複数当事者間取引の処理

1 件のマーケットプレイス取引には、買い手、1 つのカート内の複数の売り手、プラットフォーム手数料、紹介手数料に加え、物流を担う別の事業者が含まれることもあります。API は、1 回の決済イベントを、これらの当事者間で行われる複数の送金に変換します。

複数当事者間取引には、主に 2 つのアーキテクチャ上のアプローチがあります。

• デスティネーション支払い: デスティネーション支払いでは、決済額全体がまずプラットフォームに送られ、その後、プラットフォームが売り手に適切な金額を送金します。プラットフォームが顧客との関係を担い、買い手のカード利用明細にマーチャントオブレコードとして表示されます。このモデルでは、プラットフォームの管理範囲が広がる一方で、責任も大きくなります。

• ダイレクト支払い: ダイレクト支払いでは、決済は売り手の連結アカウントで直接処理されます。売り手がマーチャントオブレコードとして表示され、プラットフォームはプラットフォーム手数料を回収します。これは、個々の売り手との関係がより重要なサービス型マーケットプレイスで一般的です。

どちらが適切かは、マーケットプレイスがどのように構成されているかと、取引の責任を誰が負うかによって異なります。

複数当事者間取引では、次の点も考慮する必要があります。

• 分割決済: 1 つのカートに複数の売り手の商品が含まれている場合、API は、プラットフォーム手数料を差し引いたうえで、合計金額を適切な比率ですべての関連アカウントに分配します。

• 入金タイミング: プラットフォームは、売り手に資金を送金する前に、一定期間その資金を保留できます。これは、取引が確認されるまで、または不審請求の申し立て期間が終了するまで送金すべきでないマーケットプレイスで一般的です。Stripe Connect などのツールを使うと、プラットフォームはアカウント単位で入金スケジュールを設定できるため、モデル上必要であれば、売り手のカテゴリごとに異なるタイミングで入金できます。

マーケットプレイス決済に適用される規制要件

決済は厳しく規制されています。プラットフォームが他者に代わって資金を移動する場合、そのコンプライアンス負担をどの程度直接負うかは、API インフラによって決まります。

こうしたコンプライアンス上の義務や規制上の義務は、プラットフォームにとって想定外の負担になることがあります。

顧客確認 (KYC) と売り手の本人確認

多くの管轄区域では、第三者への決済を仲介するプラットフォームは、「顧客確認 (KYC)」と呼ばれるプロセスで、それらの当事者の本人確認を行う必要があります。規制当局は、確認されていない資金受取人をマネーロンダリングのリスクとみなすため、このステップを省略するプラットフォームは法的リスクを負う可能性があります。

API レイヤーは、売り手のアカウント登録体験を煩雑にすることなく、本人確認 (正式な氏名、納税者番号 (ID)、生年月日、事業登録の詳細の収集など) に対応する必要があります。Stripe Connect は、プラットフォームに代わって KYC を処理します。売り手が連結アカウントを作成すると、Stripe は必要な情報を収集して確認し、売り手の国で適用される規制に照らして確認を行い、確認できないアカウントにフラグを付けます。

税務申告

アメリカでは、商品またはサービスについて受け取った決済の総額が、200 件を超える取引で 2 万ドルを超える場合、プラットフォームは 1099-K レポートを発行する必要があります。EU では、2023 年 1 月 1 日に施行された行政協力指令の第 7 次改正 (DAC7) により、マーケットプレイスは売り手の収入を税務当局に報告することが義務付けられています。API レイヤーでは、アカウント登録時に売り手の税務情報を収集し、その後の報告フローに対応する必要があります。

カードデータを処理するすべてのシステムでは、Payment Card Industry Data Security Standard (PCI DSS) への準拠も必要です。すでに PCI DSS に準拠した決済 API を使用すれば、プラットフォームがその認証を個別に取得する必要はありませんが、対象範囲内に収めるために API を正しく実装する必要があります。

マーケットプレイス決済 API における不審請求の申し立てと返金の処理

連携の構築時に行うマーケットプレイスのアーキテクチャ上の判断によって、不審請求の申し立ての解決方法が決まります。デスティネーション支払いモデルでは、プラットフォームが不審請求の申し立てに対応します。不審請求の申し立てに正当性がある場合は、売り手のアカウントから資金を回収する必要があります。ダイレクト支払いモデルでは、不審請求の申し立ては売り手のアカウントに対して直接行われます。

同様に、返金プロセスも事前に設定しておく必要があります。プラットフォームがすでにプラットフォーム手数料を回収している取引に対して売り手が一部返金を行う場合、このシナリオを処理できるよう API を設定する必要があります。売り手が返金を行った際にプラットフォーム手数料を自動的に返すのか、それとも留保するのかを事前に決めておく必要があります。これを未定義のままにすると、会計上の抜け漏れが生じます。

一部のプラットフォームでは、将来的な不審請求の申し立てに備えて、売り手の資金の一定割合を保留します。リザーブポリシーがリスクモデルの一部である場合、API はそれに対応する必要があります。不審請求の申し立て期間が終了する前に売り手へ入金すると、資金回収の問題が生じます。プラットフォームでは、買い手が決済に対して不審請求の申し立てを行える期間を考慮して、入金の遅延を設定する必要があります。

不審請求の申し立てに対抗するには、取引記録、配送確認、コミュニケーションログが必要です。プラットフォームはこのデータを取得しておく必要があり、不審請求の申し立てへの対応を準備する際に決済 API からアクセスできるようにしておく必要があります。

マーケットプレイス向け決済 API を選ぶ際のポイント

マーケットプレイス向け決済 API を選ぶ際は、いくつかの具体的な基準を検討する必要があります。この初期段階での選択、特に決済方式と入金モデルに関する選択は、プラットフォームに売り手が参加した後では変更しにくくなります。また、国際的に運営している場合や今後の展開を計画している場合は、買い手と売り手が所在する国での決済と入金に対応している必要があります。

マーケットプレイス決済 API を選択する際に注目すべき点は次のとおりです。

• 複数当事者への送金: API は 1 回の呼び出しで 1 件の決済を複数の受取人に分割できますか？分割された決済に対する一部返金を処理できますか？

• 売り手の確認: API は KYC にどのように対応していますか？本人確認フローを直接管理しますか、それとも自社で行う必要がありますか？複数の国で事業を展開している場合、API は各管轄区域で異なる要件に対応できますか？

• 入金の柔軟性: API は売り手への即時入金に対応していますか？マーケットプレイスが国境を越えて展開している場合、複数の入金通貨に対応していますか？

• 不審請求の申し立て管理: プラットフォームの観点から見た不審請求の申し立てフローはどのようなものですか？API はどのように売り手のアカウントから資金を回収しますか？

• 開発者エクスペリエンス: API のドキュメント、ソフトウェア開発キット (SDK)、Webhook の信頼性、サンドボックス環境を確認しましょう。

Stripe Connect でできること

Stripe Connect は、ソフトウェアプラットフォームやマーケットプレイスにおける複数者間での資金移動を可能にするツールです。迅速なユーザー登録、組み込みコンポーネント、グローバル入金などの機能を備えています。

Connect でできること

• 数週間で立ち上げ: Stripe がホストする機能または組み込み機能を活用して、本番環境にスピーディーに移行できます。決済代行に通常必要な初期費用や開発時間を削減できます。

• 大規模な決済管理: Stripe のツールやサービスを利用することで、マージンレポート、納税申告書、リスク管理、世界各国の決済手段、ユーザー登録の法令遵守に追加リソースを割く必要がありません。

• グローバルに成長: 現地の決済手段と、消費税、付加価値税 (VAT)、物品サービス税 (GST) を簡単に計算できる機能により、ユーザーが世界中のより多くの顧客にリーチできるよう支援します。

• 新たな収益源の構築: 各取引で手数料を徴収して決済収益を最適化します。プラットフォーム上で対面決済、即時入金、消費税徴収、融資、経費用カードなどの機能を有効にして、Stripe の機能を収益化できます。

Stripe Connect の詳細はこちら。今すぐ始める。