- インテグレーションガイドライン
- サポートされている機能(セキュリティ)
- ゲートウェイ<<tokenization>>
ゲートウェイ<<tokenization>>
ゲートウェイ<<tokenization>>によって、トークンと引き換えに支払詳細を格納できるようになります。トークンは、ゲートウェイに送信される取引リクエスト内の支払詳細を置き換えます。この場合、支払者から収集された支払詳細がゲートウェイによって処理されるため、PCI コンプライアンス準拠義務を軽減するのに役立ちます。また、トークンが支払者のデータとともに格納されている場合、その支払者が他の商品を購入するために戻ったときにそのトークンを使用できます。
トークンとは何か?
トークンとは、格納されている支払詳細の識別子です。支払詳細をトークン化すると返されます。トークンは、以前に保存した支払詳細を参照し、後続のすべての支払取引で使用できます。
トークンは PAN 形式であり、単純なカード検証ルールを渡すので、クレジットカード番号の代わりに保管できます。ただし、それらが有効なカード番号となる可能性を最小限に抑えて生成されるように設計されています。
主な利点
- 支払詳細を処理または保管しないので、PCI コンプライアンス費用が削減されます。
- スタッフがアクセスできる支払詳細情報が制限されるので、内部不正行為が低減されます。
- トークンに対して保管されている支払詳細を更新できます。これは、支払詳細が期限切れになるか変更される場合、または支払者が支払方法を変更する場合に便利です。
- 現状でカード番号をリクエストするシステムにトークンを簡単にインテグレーションできるようにします。システムによって生成されたトークンは、カード番号のように表示され、基本的なカード検証チェックに合格します。
- トークンから支払詳細を取得できます。
- 支払詳細を検証するためのさまざまなオプションが提供されます。
- トークン管理のための柔軟なオプションを提供します。
- 他の加盟店とトークンを共有できます。
例
- 登録型課金 (光熱費、ジムの会員費など):支払者から支払詳細を収集し、トークンと引き換えに格納します。トークンは支払期限が到来するたびに決済手段としてゲートウェイに送信されます。これは、PMI のコストを削減したい場合に便利です。
- オンライン小売店 (オンラインショッピングのカート、オンライン請求書の支払い、ゲームサイト):Web サイト上で支払者から支払詳細を収集し、トークンと引き換えに格納します。返されたトークンは支払者のデータとともに格納されます。支払者が他の商品を購入するために Web サイトに戻ると、マスキングされた口座識別子 (または、「先頭 6 桁と末尾 4 桁を保持」を使用している場合は、トークンの最後の 4 桁) を提示し、支払詳細を再入力しなくてよいことを示します。これにより、支払者が支払詳細の一部または全部を再入力せずに済みます。これにより、Web サイト経由で商品を購入する際の利便性と支払者のユーザーエクスペリエンスが向上します。
ゲートウェイ<<tokenization>>の設定
決済代行会社は以下のパラメータに対して加盟店プロファイルと関連付けられている<<tokenization>>サービスを設定できます。
支払詳細が格納される前に検証される方法を定義します。値の選択肢は次のとおりです。
基本 | 提供された支払詳細が、それらの支払詳細で支払いを処理するためのゲートウェイルールに準拠していることを検証します。 |
Acquirer |
提供された支払詳細をアクワイアラーに確認するために、<<webServicesIntegration>> Verify 要求を実行して、支払詳細を確認します。
トークンを保存する場合、通貨を提供する必要があります。取引ソースは、加盟店とアクワイアラーのリンクに設定した値にデフォルト設定されます。この取引ソースの
Enforce CSC 設定は無視されます。 |
なし | 確認は実行されません。 |
リポジトリ内のトークンを管理する方法を定義します。値の選択肢は次のとおりです。
一意のトークン | 口座識別子を保存するたびに一意のトークンを割り当てます。これは、口座識別子とトークンとの間の 1 対多の関係として定義できます。 |
一意の口座識別子 | 口座識別子は、1 つのトークンに対してのみ保存できます。別のトークンに対してそれを保存しようとするとエラーになります。これは、口座識別子とトークンとの間の 1 対 1 の関係として定義できます。 |
このリポジトリ内でトークンを生成するのに使用される方法を定義します。値の選択肢は次のとおりです。
ランダム (Luhn を使用) | 生成されるトークン ID はランダムな数字です。これは「9」から始まり、Luhn (Mod-10)チェックに合格します。既知のカード番号は除外されます。 | ||||||||||||||||||||
先頭 6 桁と末尾 4 桁を保持 | 最初の 6 桁と最後の 4 桁を保持しようとします。これは有効なカード番号ではありません。 トークンのプロパティ:
「先頭 6 桁と末尾 4 桁を保持」トークン用にカード番号を更新することはできませんが、有効期限を更新することはできます。
|
||||||||||||||||||||
加盟店指定 | トークンは加盟店によって指定されます。加盟店が供給したトークンはすべて、有効なカード番号ではないことが確認されます。 | ||||||||||||||||||||
アクワイアラーのトークン化 | トークン ID はアクワイアラーのトークン化サービスによって指定されます。このサービスは、FPAN をトークンに保存することのみに利用できます。アクワイアラーのトークン化を許可するには、以下の前提条件を成就する必要があります。
|
トークン操作
ゲートウェイ<<tokenization>>ソリューションを使用して次の操作を実行できます。
この操作を使用し、トークンに対して支払詳細を格納することでトークンを作成または更新できます。トークンは、加盟店プロファイルの設定に従ってトークンリポジトリに格納されます。
verificationStrategy
フィールドに設定された確認方法を使用して、支払詳細が検証されます。このフィールドが設定されていない場合は、加盟店プロファイルに設定されているデフォルトの方法が使用されます。
確認が成功した場合、支払詳細はトークンに対して保存され、後に参照して後続の支払取引で使用されます。最初の試行がレスポンスを返さない場合は、Tokenize 操作を再試行することもできます。
トークンは加盟店プロファイルで使用されるトークンリポジトリ用に設定されたトークン管理方法に基づいて発行されます。
すべての詳細を再取得せずにトークンを更新
Tokenize 操作を使用して、保存されたトークンの詳細 (例: カードの有効期限) を更新し、その他の詳細は変更しない場合も考えられます。リクエスト URL で指定するトークンは、更新するトークンを識別します。この同じトークンを支払詳細のソースとして指定すると、以前保存された詳細が再利用されます。つまり、支払詳細を再取得する必要はありません。リクエストの [カードの詳細] セクションで新しい有効期限を提供することで、その値はトークンに保存済みの有効期限を上書きします(「優先ルール」を参照)。
次のリクエストの例では、Tokenize リクエストでカードの詳細とトークンの両方のソースを提供する方法を示します。
HTTP メソッド | PUT |
URL | https://qnbalahli.test.gateway.mastercard.com/api/rest/version/72/merchant/<merchant>/token/9999999999999999 |
JSON |
{ "sourceOfFunds": { "provided": { "card": { "expiry": { "month": "01", "year": "39" }, "number": "5123456789012346" } }, "type": "CARD" } } |
上記の JSON では、「9999999999999999」という ID を持つトークンが以前保存され、カード番号と有効期限が含まれていると想定しています。
この操作の結果、トークン「9999999999999999」の有効期限は 05/21 となり、カード番号は変更されません。
指定したトークンに対して保存された支払詳細を取得できます。口座識別子およびその他の機密認証データがマスキングされて返されます。
クエリに一致するトークンレコードを検索します。クエリは、現在、トークン識別子または口座識別子を使用した検索をサポートします。JWE.js ライブラリを使用し、必ずカード番号を暗号化してください。
クエリが大量のトークンレコードに一致する場合、返される検索結果を 1 ページに制限し、後続のリクエストを使用して次の結果セットを取得できます。
<<tokenMaintenanceService>>
ゲートウェイが提供する <<tokenMaintenanceService>> は、可能な限り、登録型決済のために使用されるトークンに対して格納されている支払詳細が最新で、このトークンを使用した登録型決済取引の処理がほとんど成功するようにします。
次の処理では、<<tokenMaintenanceService>> を使用してください。
- ゲートウェイを介して登録型決済を処理します。
- ゲートウェイのトークン化を使用して、登録型決済に使用されるクレジット支払詳細を安全に保管します。
- <<webServicesIntegration>> とバッチの両方またはいずれかを使用してトークンを管理し、処理のために取引を送信します。
<<tokenMaintenanceService>> を使用するには、次の内容を実施する必要があります。
- アクワイアラーやカードスキームが使用するアカウントアップデーター機能に参加します。
- 決済代行会社に依頼して、加盟店アクワイアラーのリンク上でアカウントアップデーターを有効にします。
- <<tokenMaintenanceService>> を有効にするには、決済代行会社に確認してください。<<tokenMaintenanceService>> またはネットワークトークン化のいずれか (両方ではない) のみを有効にできることに注意してください。両方の機能により、トークンに対して保存された支払詳細は最新の内容に維持されるようになります。
アカウントアップデーター対応のアクワイアラー経由でゲートウェイによってトークンが提供され、取引が正常に処理された登録型取引の場合、登録型決済のためにトークンが使用される次の日付は、(以前の登録型決済におけるトークンの使用に基づいて)ゲートウェイによって決定されます。
ゲートウェイは、レスポンスの受信および処理に合うように、トークンに対して格納されている支払詳細に関するリクエストをアカウントアップデーターサービスに送信します。ゲートウェイはその後、レスポンスに応じてトークンを更新します。
トークンの更新には次の内容が含まれます。
- カード番号と有効期限。
- カードの有効期限のみ。
- トークンが無効にマークされる。
アカウントアップデーターのレスポンスが、トークンに対して格納されている支払詳細が無効であることを示している場合、トークンは無効にマークされます。
無効なトークンを使用した取引リクエストは、ゲートウェイによって拒否されます。
無効なトークンに対しては、<<webServicesIntegration>> の RETRIEVE_CARD 操作のレスポンスが status=INVALID
を返します。
Retrieve Token 操作を使用して、アカウントアップデーターによって更新されたトークンの支払詳細を取得します。
usage.lastUpdated
は、そのトークンがアカウントアップデーターによって更新された日付と時刻です。usage.lastUpdateBy
が空であれば、そのトークンが加盟店ではなくアカウントアップデーターによって更新されたことを表しています。
<<webServicesIntegration>> の SEARCH_TOKEN 操作を使用すると、指定した日時以降に更新されたすべてのトークンを検索できます。レスポンスでは、リクエストに指定された日時以降の usage.lastUpdated
日時を持つすべてのトークン (トークンに対して保管された支払詳細、およびトークンの使用情報などを含む) が提供されます。
たとえば、次のような処理に既存のプロセスを使用できるようになりました。
- 取引のレスポンスで返されるマスキングされた新しいカード番号または有効期限 (あるいはその両方) を使用してシステムを更新します。
- お客様に連絡し、無効なトークンの新しい支払詳細を取得します。
- 必要に応じて、新しいトークンを作成します。
手動によるトークンの更新
加盟店アクワイアラーリンクのアカウントアップデーターが有効になっている場合、トークンに保存されているカード詳細のアカウント更新情報を手動でリクエストできます。これを行うには、Tokenize リクエストで以下を提供する必要があります。
verificationStrategy=ACCOUNT_UPDATER
transaction.currency
sourceOfFunds
パラメータグループの提供は任意であることに注意してください。
ゲートウェイは、<<tokenMaintenanceService>> が使用された場合と同様に、アカウントアップデーターサービスからレスポンスを受信し、処理します。トークンの更新に何が含まれるか、無効なトークン、トークン更新情報の取得については、「<<tokenMaintenanceService>>」の下のセクションを参照してください。
代替トークン
アクワイアラーからカード番号が変更されたことを示すアカウントアップデーターのレスポンスをゲートウェイが受信した場合、トークンの生成またはメンテナンス方法により、ゲートウェイはカードの詳細を更新することができません。代わりに、ゲートウェイは新しい資金調達主口座番号 (FPAN) で新しいトークンを作成し、replacementToken フィールドを使って新しいトークンを古いトークンにリンクさせます。
このセクションでは、加盟店が代替トークンを使用し、古いトークンを削除する必要がある場合のさまざまなシナリオについて説明します。
この表では、代替トークンが生成されるいくつかのシナリオを説明します。
事例 1 |
|
事例 2 |
|
PayPal 請求契約 ID のトークン化
PayPal は、支払者のために請求契約を設定できるようにしています。これにより、請求契約を参照することによって、支払者の同意なく後に支払者に請求ができるようになります。支払者は、請求契約を締結した時に、その請求契約に対して 1 回同意をするだけです。請求契約の設定時に、支払いを行うことも、行わないこともできます。
PayPal 請求契約 ID は、Tokenize 操作でトークン化できます。Tokenize リクエスト URL に、ゲートウェイが生成または加盟店が指定したトークン ID を提供します。
URL | https://qnbalahli.test.gateway.mastercard.com/api/rest/version/72/merchant/<your_gateway_merchant_ID>/token/<token_ID> |
HTTP メソッド | PUT |
{ "sourceOfFunds": { "provided": { "paypal": { "billingAgreement": { "description": "Test Billing Agreement", "name": "Test Name", "cardinality": "MULTIPLE", "id": "1234" } } }, "type": "PAYPAL", "token": "9926675679589987" }, "shipping": { "address": { "city": "city", "country": "country", "postcodeZip": "post_code", "stateProvince": "state", "street": "test street", "street2": "test street2" } } }
インテグレーションのテスト
本番環境でテスト用加盟店プロファイル (接頭辞 に TEST が付いている加盟店 ID) を使用することで、ゲートウェイのトークン化のインテグレーションをテストできます。
決済代行事業者によってトークン化が有効になっており設定されている場合、ゲートウェイはテスト用と本番用に 2 つのリポジトリを作成します。テスト用リポジトリは、TEST という接頭辞が付いたトークンリポジトリ ID です。
テスト用加盟店プロファイルを使用してゲートウェイにトークン化リクエストを送信すると、テスト用トークンリポジトリが使用されます。後でトークンを使用して支払いを処理するには、サポートされているテスト用カード番号をトークン化する必要があります。テスト用カードの詳細については、「テストと実際の取引処理の開始」をご覧ください。