EC 向けトークン検証

デジタルカードへの信頼を次の後に高めるために、このフローを使用します トークナイゼーション.

これは、カードオンファイル（COF）およびeコマースのユースケースで使用されるトークンに適用されます。近接型決済トークンとは異なり、これらのトークンは決済ネットワークのTSPによって保存されます。デバイスにはプロビジョニングされません。

加盟店は通常、機密性の高い操作の前にトークン検証を要求します。トークンをデバイスまたはパスキーに紐づける前にも要求できます。

対応する決済ネットワークのフロー

Visa と Mastercard は、このフローを異なる名称でサポートしています:

• Visa: クラウド・トークン・フレームワーク (CTF)
• Mastercard: 安全なカードオンファイルとClick to Payのためのトークナイゼーション後認証

検証リクエストの種類

トークン検証リクエストには2種類あります:

1. トークンをデバイスまたはパスキーに紐づける。トークンはクラウドベースであるため、紐づけることで加盟店はデバイスの機能を利用してトークン取引を保護し、トークンの使用を特定のデバイスに制限できます。紐づけには対象デバイスでのカード所有者検証が必要なため、信頼性が高まります。同じトークンを複数のデバイスに紐づけることはできますが、通常は各デバイスごとにカード所有者検証が必要です。
2. カード所有者検証を要求する。加盟店アプリケーションまたはウェブサイトにログインしているエンドユーザーは、メールアドレスやパスワードの変更など、機密性の高い操作を実行する場合があります。アカウントに支払い方法が保存されている場合、加盟店はエンドユーザーの本人確認のためにカード所有者検証を要求できます。加盟店がトークンを紐づけられない場合は、信頼性を高めるために、チェックアウト時に定期的にカード所有者検証を要求できます。 Mastercard はまだこのフローをサポートしていません。

D1 が行うこと

どちらの場合も、D1 はイシュアを代表してフローをオーケストレーションします。イシュアのバックエンドで追加のワークフローを実装する必要はありません。

イシュアのバックエンドは、D1 が要求したときにエンドユーザーの詳細を返すだけで済みます。その後、D1 は D1 オンボーディング時に定義された設定に従って、イシュアを代表して利用可能な ID&V 手段を選択します。

イシュアの義務

選択した統合モデルにかかわらず、イシュアはエンドユーザーの詳細を提供し、それらを正確に保つ必要があります。

D1 はこのデータを使用して、ID&V 手段の一覧を構築します。

判定結果

各リクエストについて、D1 は決済ネットワークのTSPが期待する判定値を返します:

• 緑: 承認
• 黄: 承認して ステップアップ認証
• 赤: 拒否

D1 はイシュアに代わって判定を管理します。

D1 は返しません 緑 これらのリクエストでは返しません。このプロセスにより、eコマーストークンの保証レベルが向上します。初回の承認は、PAN や有効期限などの有効なカード詳細のみに依存します。悪意のある者はこれらの詳細を取得できます。したがって、カード詳細が漏えいしている場合、トークン作成は不正である可能性があります。

対応する ID&V 手段

通常どおり、判定が 黄, ステップアップ認証 必要です。D1 は、サポートされている ID&V 手段を、決済ネットワークの TSP に返す判定に追加します。

D1 は次の手段をサポートしています:

• SMS またはメールで送信される OTP を使用した ID&V
• イシュアアプリケーションを通じた ID&V。これは次の2つの方法で実現されます:

  • 加盟店アプリケーションがイシュアアプリケーションを起動します。標準のトークナイゼーションフローと同様です。参照: アプリ内認証.
  • イシュアがプッシュ通知を通じて自社アプリケーションを起動します。これは Mastercard のみでサポートされています。

ID&V 手段の前提条件

D1 が利用可能な ID&V 手段を管理できるようにするには、イシュアは次の前提条件を満たす必要があります:

1. エンドユーザーの連絡先情報が利用可能であること。
2. イシュアアプリケーション情報が設定されていること。同じトークナイゼーション要件が TSP にも適用されます。参照: アプリ内 ID&V を統合する.
3. D1 オンボーディング時に確立された設定には次が含まれます:

   1. サポートされている ID&V メソッド。
   2. OBO オプションが有効な場合の SMS およびメールのテンプレート。
   3. 〜の実装 OTP を配信 API。OBO オプションが有効でない場合。

OBO オプションは、特定のユースケースに対して有効にできません。たとえば、Tokenization 後のリクエストでは有効にできず、Tokenization リクエストでは無効にできません。

ユーザー体験

OTP が検証用に選択されたときのエンドユーザーのジャーニー：

イシュアアプリケーションが検証方法として選択されたときのエンドユーザーのジャーニー：

高レベルのフロー

次の図は、トークン検証リクエストにおける関係者と主な手順を示しています:

トークン検証の高レベルフロー。

エンドユーザーの選択に応じて、検証にはOTPまたはイシュアアプリケーションが使用されます。

SMSまたはメールによるOTP検証

SMSまたはメールによるOTP検証フロー。

イシュアアプリケーションによる検証

イシュアアプリケーションを介した検証フロー。

ステップ9における加盟店アプリケーションとイシュアアプリケーションの連携は、Thalesの範囲外です。

トークナイゼーションフローの場合と同じペイメントネットワークのガイダンスを使用してください。参照 アプリ内 ID&V を統合する。支払いネットワークが発信元のユースケースを識別するために追加する追加データを処理します。

特に：

• Visaでは、トークン化フローの検証に比べて以下のデータが追加されます：

項目	紐付け要求	カード所有者検証要求
デバイスID	デバイスに割り当てられたID	-
デバイスインデックス	デバイスへの参照	-
理由コード	トークン_デバイス_バインディング	カード所有者_STEPUP
ライフサイクルトレースID	リクエストを追跡する一意のID	リクエストを追跡する一意のID

• Mastercardは、トークン化フローの検証と比較して、次のデータを追加します：

項目	紐付け要求	カード所有者検証要求
認証相関ID	リクエストを追跡する一意のID	該当なし

次のステップ

• デバイスバインディングについては、以下を参照してください トークンバインディング.
• カード所有者の確認については、参照してください カード所有者の確認フロー.