主要概念

開発

リクエストを送受信するには、イシュアのバックエンドがインバウンドおよびアウトバウンドの実装を行う必要があります イシュアゲートウェイAPI.

イシュアのバックエンドはPKCS#7のアプリケーションレベル暗号化に対応している必要があります。PANや有効期限などの機微データを保護するために使用してください。詳細は次に説明されています データ暗号化とセキュリティ.

サンドボックス環境の構成からこれらの鍵を使用してください：

• Thalesの公開鍵。Thalesに送信する機微データを暗号化します。
• サンドボックスの秘密鍵。Thalesから受信した機微データを復号します。

本番環境では、イシュアが秘密鍵を生成して保管します。イシュア証明書を本番構成ポータルでThalesに提供してください。

用語集とデータモデル

以下の図と表は、イシュアゲートウェイAPIを通じて交換される主要な識別子について説明しています。

イシュアゲートウェイAPIパラメータ	説明
issuerCardRefId	を識別します FPAN イシュアのバックエンド内の。 カードレベルのユースケースについて、将来のイシュアゲートウェイAPI呼び出しでこの識別子を使用してください。 PANが置き換えられた場合（例えば、カードの交換や更新）にはこの識別子を更新してください。
virtualCardId	トークンの一意の識別子。
walletCardRefId	ウォレットプロバイダによって参照されるカードを識別します。 今後のウォレットプロバイダとThales間のAPI呼び出しでこの識別子を使用してください。 コーベッディングの場合、決済ネットワークがこの識別子を生成することがあります。 この値をにマップしてください walletCardRefId イシュアゲートウェイAPIでイシュアのバックエンドに送信します。 この値をにマップしてください cardRefId TSP APIでにマップし、TSPに送信します。
walletVirtualCardId	トークンPAN（DPAN）。将来のウォレットプロバイダとThales間のAPI呼び出しでこの識別子を使用してください。 コーベッディングの場合、決済ネットワークは主トークンのためにこの識別子を生成します。Thalesは補助トークンのためにそれを生成します。
tokenStorageId	デバイス上のトークン保管場所を識別します： セキュアエレメントベースのデバイスのためのセキュアエレメントID。 のためのアプリケーションインスタンスID HCEベースのアプリケーション。 この値をイシュアゲートウェイAPIを通じてイシュアのバックエンドと共有します（ tokenStorageId.

カードのデジタル化

カードのデジタル化は、物理カードをトークンに変換します。トークンはデジタルカードを表します。これはカード登録とも呼ばれます。

このプロセスには主に4つの関係者が関与します：

• カードをデジタル化したいエンドユーザ。
• 決済ネットワークに接続されたウォレットプロバイダ。
• トークンを発行するTSP（トークンサービスプロバイダ）。
• カード口座を保有するイシュア。

Thales TIG もフローに参加します。TIGは決済ネットワークとイシュアのバックエンドの間のゲートウェイとして機能します。イシュアゲートウェイAPIを公開し、決済ネットワークのAPIを抽象化します。

各カード登録にはイシュアの判断が必要です。イシュアは次のことができます：

• 追加の認証なしでリクエストを受け入れる。
• （識別と検証）を使用したステップアップ認証でリクエストを受け入れる。 ID&V （識別と検証）。
• リクエストを拒否する。

下の図は基本的なカードのデジタル化フローを示しています。

各フローには“色”があります。これはウォレットプロバイダの推奨とイシュアの判断を表します。

エンドツーエンドのフローについては、次を参照してください ユースケース.

フローの色

ウォレットプロバイダと決済ネットワークに応じて、ウォレットプロバイダは次の推奨を送信できます：

• デジタル化する（緑）
• ステップアップ認証でデジタル化する（黄色）
• 不正の疑いでデジタル化する（オレンジ）

この推奨とリスクスコアに基づいて、イシュアは次の判断で応答します：

• デジタル化する（緑）
• ステップアップ認証でデジタル化する（黄色）
• 登録を停止する（赤）

イシュアゲートウェイAPIはパラメータを使用して色を管理します levelOfTrust 。このパラメータはカードのデジタル化APIリクエスト（ウォレットプロバイダ）とレスポンス（イシュア）に存在します。以下のセクションでは一般的なケースを説明します。

ウォレットプロバイダからの推奨

緑

• エンドユーザを信頼することを推奨します（例：Card-on-file（COF）やデバイスのペアリング）。イシュアは通常リクエストを信頼できます。

黄色

• エンドユーザを認証するためにID＆Vフローを使用することを推奨します。イシュアはID＆Vを要求するべきです。

オレンジ

• 不正の疑いやデバイスの整合性の問題（例：ルート化されたデバイス）を示します。イシュアはリクエストを拒否するか、ID＆Vを要求することができます（例：カスタマーサービス経由）。

イシュアからの判断

イシュアはウォレットプロバイダの推奨とスコア情報を受け取ります。イシュアはそれから独自のを返します。 levelOfTrust。以下のケースが一般的です：

緑

• リクエストを信頼し、追加の検証を要求しない。ID＆Vフローはトリガーされません。

黄色

• 追加の検証を要求する。リクエストに信頼シグナルが欠けている場合に使用します。例：CVVが欠落している、または黄色の推奨。イシュアはサポートされるID＆V方法を返します。

赤

• リクエストを拒否する。シグナルが高リスクを示す場合に使用します。例：無効なCVV、繰り返しのCVV失敗、またはオレンジの推奨。