クレジットカードのトークン化と複数の当事者
ビジネスBはSAQ-A-EPガイドラインに基づいてクレジットカード情報を受け入れ、支払いサービスプロバイダーPからトークンTを取得します。トークンを（Bによって）パートナーP1またはP2またはP3に送信する必要があります。パートナーが提供するサービスについて、Bの顧客に請求する。
これは実行可能なシナリオですか？言い換えれば、企業はトークンを転送し、パートナーに処理のためのトランザクション情報を追加させることができますか？そうでない場合、基本的に仲介業者として機能するビジネスは、パートナーを通じて支払いをどのように処理しますか？
ゴングが使用するソリューションは、トークンをEODファイルで送信し、パートナー情報とともに支払いプロバイダーに送り返すことです。パートナーも支払い提供と関係を持っている必要があります。支払いプロバイダーはパートナーの新しいトークンを作成し、それは支払い処理に使用されます。
これは実行可能なシナリオですか？言い換えれば、企業はトークンを転送し、パートナーに処理のためのトランザクション情報を追加させることができますか？
通常、いいえ-DSSがトークンの共有を禁止しているためではありませんが、トークンは、プロセッサーとマーチャントの間の関係のコンテキストでのみ有用です。ランダムパーティーP1-P3は、トークンをプロセッサーに提示して、プロセッサーにそれを実行させることはできません。また、プロセッサによって1つの販売者に提供されるトークンは、同じプロバイダーを使用する他の販売者に移植できない場合があります。
そうでない場合、基本的に仲介業者として機能するビジネスは、パートナーを通じて支払いをどのように処理しますか？
Payment Facilitator 、またはPayFac *モデルのようなものを探しているようです。これにより、マーチャントBはP1/P2/P3（このモデルでは「サブマーチャント」）とプロセッサーPの間の仲介者として機能できます。PayFacBは通常、サブマーチャントが支払いフローをルーティングするためのインターフェースを提供します。 Bの後援の下でプロセッサPを使用して、Pから集計された通貨分布を取得し、正しい内訳をP1/P2/P3に分散します。カードのデータとトークンはBに残ります。 P1/P2/P3の顧客は、将来のトランザクションのためにBを通過します（通常、そうしていることは明らかではありません）。
" Payment Gateway "は、支払いファシリテーターを説明するためによく使用される用語の1つですが、 "Payment Gateway"には、PayFac以外のさまざまな設定andは、人によって異なることを意味します。
基本的に、P1/P2/P3は、カードの処理の複雑さをPayFac、Bに引き継いでいます。しかし、カードを受け入れることでビジネスを可能にするという利点があります。
* PayFacはこの種のセットアップのVantiv用語です。一般的な用語があるのか、競合する製品の名前は何なのかわかりません。完全な開示、私はVantivの従業員です。例をVantivに限定することは、それ自体が偏見ではなく、私の無知のしるしです:)コメントで競合する同等のものを誰かが挙げた場合、私はそれらを回答自体にバブルアップしてうれしいです。