网关 <<tokenization>>
网关 <<tokenization>> 允许您存储用于替换令牌的付款详细信息。令牌替换发送到网关的交易请求中的付款详细信息。当网关处理从付款人处收集的付款详细信息从而减少您的 PCI 合规义务时,此方法非常有用。此外,如果令牌存储在付款人数据中,则可以在付款人返回再次进行购买时使用。
什么是令牌?
令牌是存储的付款详细信息的识别码;在您对这些信息令牌化时返回。令牌可以用于所有后续付款交易以参考之前保存的付款详细信息。
令牌采用 PAN 格式并将通过简单的卡验证规则验证,以便可以在存储后代替信用卡号。不过,生成规则的目的是最大程度地降低令牌成为有效卡号的可能性。
主要优点
- 您不处理或存储任何付款详细信息,因而降低了 PCI 合规成本。
- 您的员工只能有限访问付款详细信息,因而减少了内部欺诈。
- 允许您更新按令牌存储的付款详细信息。当付款详细信息过期/改变或付款人希望更改付款方式时,此功能非常有用。
- 促使简化令牌到当前预计卡号的系统的集成。系统生成的令牌能够看似卡号并通过卡验证检查。
- 允许您从令牌检索付款详细信息。
- 为验证付款详细信息提供不同选项。
- 提供灵活的令牌管理选项。
- 允许您与其他商家共享令牌。
示例
- 重复计费(帐单、健身会员等):从付款人处收集付款详细并存储这些信息换取令牌。每次付款到期时,令牌被作为支付工具提交至网关。如果您希望减少 PCI 成本,此方法很有用。
- 在线零售商(在线购物车、在线账单付款、游戏网站):在网站上从付款人处收集付款详细并存储这些信息换取令牌。返回的令牌与付款人数据一并存储。当付款人返回网站再次购物时,您显示隐藏账户识别码(或者如果使用“保留 6.4 生成策略”则为 PAN 后四位数)并指示不必重新输入付款详细信息。这样付款人可以免于重新输入部分或全部付款详细。这改进了通过您的网站购物的便利性和付款人的用户体验。
配置网关 <<tokenization>>
您的支付服务提供商可以针对以下参数配置与您的商家配置文件关联的 <<tokenization>> 服务:
定义如何在存储付款详细信息前对其进行验证。值可能是:
基本 | 验证所提供的付款详细信息符合使用这些信息处理付款的网关规则的要求。 |
收单行 |
通过执行 <<webServicesIntegration>> Verify 请求来验证付款详细信息,以向收单行确认所提供的付款详细信息。
存储令牌时必须提供货币。交易来源将默认为为商家收单行链接配置的值。此交易来源的
对于使用 DPAN 的设备付款交易,如果商家的令牌验证策略配置为收单行,令牌验证策略会自动回退到基本策略来处理该交易。
Enforce CSC 设置将被忽略。 |
无 | 不执行验证。 |
定义如何管理令牌库中的令牌。值可能是:
唯一令牌 | 在每次保存账户识别码时分配一个唯一令牌。这样可定义为账户识别码与令牌之间的一对多关系。 |
唯一账户识别码 | 账户识别码只能使用单个令牌存储。如果尝试用另一个令牌来存储账户识别码,则会出错。这可定义为账户识别码与令牌之间的一对一关系。 |
定义用于在此令牌库中生成令牌的策略。值可能是:
通过 Luhn 随机生成 | 生成的令牌 ID 是随机号码。它以“9”开头,通过 Luhn(模 10 算法)校验并排除已知卡号。 | ||||||||||||||||||||
保留 6.4 | 尝试保留前 6 位和后 4 位数字,不是有效的卡号。 令牌属性:
您无法更新保留 6.4 令牌的卡号;但是,您可以更新过期日期。
|
||||||||||||||||||||
商家提供 | 令牌由商家提供。需验证任何商家提供的令牌,以确保它不是有效卡号。 | ||||||||||||||||||||
收单行令牌化 | 令牌 ID 由收单行令牌化服务提供。此服务仅允许将 FPAN 存储在令牌中。必须满足以下先决条件才允许收单行令牌化:
|
令牌操作
您可以使用网关 <<tokenization>> 解决方案执行以下操作:
您可以使用此操作通过使用令牌存储的付款详细信息来创建或更新令牌。令牌将存储在根据您的商家配置文件配置的令牌库中。
您还可以提供上一个成功订单的 reference order ID
来使用此操作创建或更新令牌,此信息最长可在网关中保留 12 个月。系统将根据参考订单中使用的付款凭据,为您提供网关令牌。令牌将存储在根据您的商家配置文件配置的令牌库中。
付款详细信息将使用在 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 假设 ID 为“9999999999999999”的令牌之前已存储并包含卡号和过期日期。
此操作的结果将是:令牌“9999999999999999”现在的过期日期为 05/21,卡号保持不变。
查找与查询匹配的令牌记录。查询目前支持使用令牌识别码或账户识别码搜索。请确保您使用 JWE.js 库为卡号加密。
如果查询与大量令牌记录匹配,您可以限制每页返回的搜索结果,并使用后续请求检索下一组结果。
<<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>> 下的各个部分。
替换令牌
当网关收到来自收单行的 Account Updater 响应,响应中指示卡号已更改时,网关将由于令牌生成或维护策略而无法更新卡详细信息。而是使用新的资金提供主账号 (FPAN) 创建一个新令牌,然后使用 replacementToken 字段将新令牌关联到旧令牌。
此部分说明商家必须使用替换令牌和删除旧令牌的不同场景。
此表描述了生成替换令牌的几个场景。
案例 1 |
|
案例 2 |
|
PayPal 账单协议 ID 令牌化
PayPal 允许您为付款人设置账单协议,让您可以在后续向付款人收款时直接引用账单协议,无需付款人同意。账单协议建立后,付款人只需要授予同意一次。付款可以在,也可以不在设置账单协议时执行。
您可以使用 Tokenize 操作对 PayPal 账单协议 ID 进行令牌化。在 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" } } }
测试您的集成
您可以在生产环境中使用测试商家配置文件(您的商家 ID,前缀为 TEST)测试网关令牌化的集成。
当您的支付服务提供商为您启用并配置了令牌化时,网关将创建两个库,即测试库和生产库。测试库是您的令牌库 ID,前缀为 TEST。
当您使用测试商家配置文件向网关提交令牌化请求时,将使用测试令牌库。后续要使用令牌处理付款,您必须将支持的测试卡号令牌化。有关测试卡的详细信息,请参见测试与投入使用。