网关 Tokenization
网关 Tokenization 让您可以令牌化付款人的敏感付款详细信息。 您可以存储一个令牌,并在发送到网关的后续交易请求中使用它来代替付款详细信息。 要使用网关 Tokenization,您首先需要定义令牌化服务配置,然后了解如何创建令牌以及如何在付款交易中使用令牌,最后决定是要自动还是手动更新令牌。
网关 Tokenization 用例
网关 Tokenization 很有用,例如,在以下用例中:
使用网关令牌进行重复计费交易
这些是使用网关令牌进行重复计费交易的阶段。 您:
- 从付款人处收集付款详细信息并将其存储为令牌。
- 每次付款到期时,将令牌提交给网关作为支付工具。 如果您希望减少 PCI 合规成本,此方法很有用。 例如,水电费、健身房会员费。
为在线零售商使用网关令牌
这些是网上零售商使用网关令牌的阶段。
您必须:
- 在网站上从付款人处收集付款详细信息,然后将其作为令牌与付款人数据一起存储。
- 如果使用 Preserve 6.4 令牌生成策略,当付款人返回网站进行另一次购买时,显示隐藏的账户识别码或 PAN 的最后四位数字,并指明付款人不必重新输入部分或全部付款详细信息。 它提高了通过您的网站购物时的便利性和付款人的用户体验。 例如,在线购物车、在线支付账单、游戏网站。
支持的方法和操作
下表介绍了网络令牌化支持的集成付款方式和操作。
集成方法 | 付款方式 | 操作 |
---|---|---|
全部 |
仅对账单协议详细信息令牌化。
|
网关在以下操作中使用令牌:
|
网关 Tokenization 的优点
网关 Tokenization 具有以下优点:
- 您不处理或存储任何付款详细信息,因而降低了 PCI 合规成本。
- 您的员工只能有限访问付款详细信息,因而减少了内部欺诈。
- 允许您更新按令牌存储的付款详细信息。 当付款详细信息过期或改变或者付款人希望更改付款方式时,此功能非常有用。
- 促使简化令牌到当前预计卡号的系统的集成。 系统生成的令牌能够看似卡号并通过卡验证检查。
- 允许您从令牌检索付款详细信息。 网关默认会返回隐藏的卡号。 如果您想要管理未隐藏的付款详细信息,这会影响到您的 PCI 合规事宜,请联系 your payment service provider (PSP)。
- 提供不同的策略,供网关用来在存储付款详细信息之前对这些信息进行验证。
- 提供灵活的令牌管理选项。
- 允许您与其他商家共享令牌。
网关 Tokenization 配置
下图说明了您的令牌化服务可以选择的配置选项。
选择您需要的选项,请您的 PSP 为您的商家配置文件配置令牌化服务:
- 令牌验证策略定义网关在存储付款详细信息之前如何对这些信息进行验证。 这些值可以是:
- 基本 验证您提供的付款详细信息符合使用这些信息处理付款的网关规则的要求。 您不需要在令牌创建请求中提供货币。
- 收单行 通过执行 VERIFY 请求验证付款详细信息,通过收单行来验证所提供的付款详细信息。
警告: 当您使用令牌创建请求存储令牌时:对于使用 DPAN 的设备付款交易,即使您的令牌验证策略为“收单行”,令牌验证策略也会自动回退到“基本”来处理该交易
- 您必须提供一种货币。
- 交易来源默认为为商家收单行链接配置的值。
- 交易来源的强制 CSC 设置会被忽略。
- 无 不进行验证。
- 令牌管理定义如何管理存储库内的令牌。 这些值可以是:
- 唯一令牌 每次保存账户标识符时分配一个唯一令牌。 例如卡号。 这样可定义为账户识别码与令牌之间的一对多关系。
- 唯一账户标识符 账户标识符只能按单个令牌存储。 如果尝试用另一个令牌来存储账户识别码,则会出错。 如果使用唯一账户标识符,只能按一个令牌存储卡的详细信息。 这可定义为账户识别码与令牌之间的一对一关系。
- 令牌生成策略: 定义在存储库中生成令牌所使用的策略。 这些值可以是:
- 通过 Luhn 随机生成: 生成的令牌 ID 是一个随机数字。 它以“9”开头,通过 Luhn(模 10 算法)校验并排除已知卡号。
- 保留 6.4: 尝试保留前 6 位和后 4 位数字,并且不是有效的卡号。
下表描述了令牌的账户识别码长度和位数。
账户识别码长度 |
令牌数字 |
---|---|
<=16 | 16 |
17 | 17 |
18 | 18 |
>=19 | 19 |
下表描述了令牌的账户识别码长度和令牌预留位数。
账户识别码长度 |
保留数位 |
---|---|
11 | 前 5 位和后 2 位 |
12 | 前 5 位和后 3 位 |
13 | 前 6 位和后 3 位 |
>13 | 前 6 位和后 4 位 |
- 商家提供: 商家提供令牌。 网关验证商家提供的任何令牌是否为有效的卡号。
- 收单行 Tokenization: 收单行令牌化服务提供令牌 ID。 此服务仅允许将资金提供主账号 (FPAN) 存储在令牌中。 确保您满足以下先决条件以允许收单行令牌化:
- 将验证卡详细信息的令牌验证策略设置为“无”。
- 将令牌库的令牌管理策略设置为“唯一账户识别码”。
- 您的 PSP 只为您设置了一个具有收单行令牌化能力的收单行链接。
有关收单行令牌化的更多信息,请联系 your payment service provider。
Hosted Checkout 的网关 Tokenization
先决条件
- 确保您的商家配置文件已启用托管付款。 请确保 Hosted Checkout 和 Pay with Token 以及相关的令牌化服务均已启用。 如果托管付款及其功能目前未启用,请联系 your payment service provider 寻求帮助。 要为您的商家配置文件激活托管付款和任何关联功能,请参见“Merchant Manager 门户”,并可以参阅“Merchant Manager 用户指南”了解详细说明。
- 请确保未启用 Secure Remote Commerce (Click to Pay)。
- 请确保您按照存档凭据集成操作并加以利用。 您可以在此处找到有关实现此集成的详细说明和指南:
- 目前,此功能支持
interaction.operation=AUTHORIZE
。 对interaction.operation=PURCHASE
的更多支持很快将推出。 - 必须使用 WS API v74 或更高版本。
- 目前,此功能支持
令牌管理
要查看网关 Tokenization 中使用的 API 请求和响应的示例,请下载 Postman 集合。
您可以使用以下操作通过 Gateway Tokenization 解决方案管理令牌:
- CREATE OR UPDATE TOKEN: 使用此操作,您可以通过按令牌存储的付款详细信息来创建或更新令牌。 网关的令牌库存储您在商家配置文件上配置的令牌。
如果您使用商家提供的令牌生成策略,使用 CREATE OR UPDATE TOKEN 请求创建令牌。 如果您的 PSP 将您配置为使用“通过 Luhn 随机生成”或 Preserve 6.4 令牌生成策略,改为使用 CREATE OR UPDATE TOKEN 和系统生成的令牌请求。 这两个请求的区别在于,在 CREATE OR UPDATE TOKEN 请求中,您需要作为路径参数提供令牌 ID,而在系统生成的令牌的 CREATE OR UPDATE TOKEN 请求中,系统生成的令牌会在响应中的令牌字段中返回
- RETRIEVE TOKEN: 允许您检索按指定令牌保存的付款详细信息。 网关隐藏并返回账户标识符和其他敏感数据。 账户标识符是在 sourceOfFunds.provided.card.number 或 sourceOfFunds.provided.giftCard.number 等字段中返回的卡号。
- DELETE TOKEN: 从令牌库中删除指定令牌。
- SEARCH TOKENS: 查找与查询匹配的令牌记录。 此查询目前支持使用以下内容搜索:
- 令牌标识符。
- 卡号。
- 礼品卡号。
- ACH 付款详细信息。
- 卡过期时间。
- 最近更新的详细信息。
如果查询匹配很多令牌记录,您可以限制每页返回的搜索结果,使用后续请求检索下一组结果。
集成方法中的令牌创建流程
不同的集成方法之间的令牌创建流程略有不同:
- Hosted Checkout: 付款人在 Hosted Payment Page 上完成付款交易后,使用 CREATE OR UPDATE TOKEN 操作存储付款人使用的付款详细信息。 在请求中,使用在 INITIATE CHECKOUT 响应中收到的会话 ID
- Hosted Session: 付款人在您的付款页的托管字段中提供了付款详细信息,并且您已在会话中更新这些详细信息后,使用 CREATE OR UPDATE TOKEN 操作存储付款人使用的付款详细信息。 在请求中,使用 CREATE SESSION 响应中收到的会话 ID
- Direct Payment 和托管 Batch: 每当您收集付款人的付款详细信息并获得批准可以存储这些信息时,使用 CREATE OR UPDATE TOKEN 操作。 在请求中提供付款详细信息。
网关使用您的 PSP 配置的默认策略来验证付款详细信息。 不过,您可以通过在 CREATE OR UPDATE TOKEN 操作的 verificationStrategy 字段中提供验证方法来覆盖默认策略。 如果验证成功,网关会按令牌保存这些付款详细信息以供参考,并可以在后续的付款交易中使用这些信息。 如果第一次尝试没有返回响应,您可以选择重试 CREATE OR UPDATE TOKEN 操作。
令牌更新
您可以通过以下方式更新令牌:
- 使用网关的自动更新功能,请参阅 Token Maintenance Service。
- 使用“账户更新程序”服务手动请求网关执行令牌更新,请参阅手动令牌更新。
- 使用 CREATE OR UPDATE TOKEN 操作仅更新令牌的特定详细信息。 例如,您可以更新卡的过期日期,同时保留其他详细信息不变。 您在请求 URL 中提供的令牌标识您想要更新的令牌。 如果您提供相同的令牌作为付款定详细信息来源,会让网关重用您之前存储的详细信息。 这意味着您无需重新捕获付款详细信息。 通过在请求的卡详细信息部分提供新的过期日期,此值将覆盖令牌中已经存储的过期日期(参见“优先规则”)。
更新示例请求
以下示例请求显示如何通过提供更新的卡详细信息和现有的令牌来仅更新 CREATE OR UPDATE TOKEN 请求中的特定详细信息:
此 JSON 示例假设 ID 为 9999999999999999 的令牌之前已存储并包含卡号和过期日期。 此操作的结果将是:令牌 9999999999999999 现在的过期日期为 01/39,卡号保持不变。
令牌在付款交易中的使用
您可以在以下付款交易中使用令牌:
照常为您选择的集成方法创建一个请求,但不要提供任何付款详细信息,而是在 sourceOfFunds.token 字段中提供令牌 ID。
使用账户更新器进行令牌维护
网关将使用卡组织和收单行提供的“账户更新器”功能让令牌保持最新:
- Token Maintenance Service 是一项网关服务,使用“账户更新器”自动确保用于定期付款的令牌保持最新。
- 您还可以手动请求网关通过账户更新器检查特定令牌是否是最新的。
- 如果您的网关 Tokenization 配置阻止网关根据需要更新令牌,网关会创建一个替换令牌并将其与旧令牌关联。
Token Maintenance Service
网关会提供 Token Maintenance Service,它可以尽可能地确保按用于定期付款的令牌存储的付款详细信息是最新的,并且使用此令牌处理的定期付款交易有可能成功。
如果您执行以下所有操作,使用 Token Maintenance Service:
- 通过网关处理定期付款。
- 使用网关 Tokenization 安全存储用于定期付款的信用卡付款详细信息。
- 使用 WS API 或 Batch API 管理您的令牌并提交交易进行处理。
先决条件
若要使用 Token Maintenance Service,您必须:
- 向您的收单行注册用于特定卡组织的账户更新器功能。
- 请您的 PSP 在您的商家收单行链接上启用“账户更新器”。
- 请您的 PSP 启用 Token Maintenance Service。
令牌更新
对于重复交易,网关会提供令牌,通过启用了“账户更新器”的收单行处理交易。 网关根据令牌上一次在定期付款中的使用来确定下次使用令牌进行定期付款的日期。
网关为按令牌存储的付款详细信息向账户更新器服务提交请求,以便网关及时接收和处理响应。 然后它根据响应更新令牌。
令牌更新包括:
- 卡号和过期日期。
- 卡过期日期。
- 将令牌标记为无效。
RETRIEVE TOKEN 操作
使用 RETRIEVE TOKEN 操作可检索“账户更新程序”更新的令牌的付款详细信息。 网关将提供在以下 RETRIEVE TOKEN 响应字段中提供的更新的详细信息:
usage.lastUpdated.time
: 指示账户更新器更新令牌的日期和时间。usage.lastUpdated.source
: 表示令牌最新更新的来源。 值GATEWAY
表示“账户更新器”或 Token Maintenance Service 功能的令牌。
Search token 操作
使用 SEARCH TOKENS 操作,您可以搜索自指定日期和时间以来更新的所有令牌。 响应为您提供所有 usage.lastUpdated 日期和时间在请求中提供的日期之后的令牌,包含通过令牌存储的付款详细信息以及令牌的使用信息。
您现在可以按照示例中提供的以下方式使用现有流程:
- 将系统更新为交易响应中返回的新隐藏卡号、过期日期或同时更新二者。
- 联系付款人为无效令牌获取新的付款详细信息。
- 根据需要创建新的令牌。
无效令牌
如果“账户更新程序”响应指示通过令牌存储的付款详细信息无效,网关会将令牌标记为无效。
网关会拒绝使用无效令牌的交易请求。
手动令牌更新
如果 your payment service provider 已在您的商家收单行链接上启用了账户更新器,您可以手动请求存储在令牌中的卡详细信息的账户更新信息。 要执行此操作,在 CREATE OR UPDATE TOKEN 请求中提供以下字段:
verificationStrategy
= ACCOUNT_UPDATERtransaction.currency
提供 sourceOfFunds 对象是可选的。
网关将收到并处理来自“账户更新器”服务的响应,与您使用 Token Maintenance Service 时一样。 有关令牌更新包含的内容、无效令牌以及检索令牌更新信息的信息,请参阅 Token Maintenance Service。
替换令牌
当网关收到来自收单行的账户更新器响应时,表明卡号已更改时,由于令牌生成或维护策略配置,网关无法始终更新卡详细信息。 在这些情况下,网关使用新 FPAN 创建一个新令牌,并使用 replacementToken 字段将新令牌与旧令牌关联
替换令牌生成场景
下表描述了生成替换令牌的场景。
表: 替换令牌用例
PayPal 账单协议 ID 令牌化
PayPal 允许您为付款人设置账单协议,让您可以在后续向付款人收款时直接引用账单协议,无需付款人同意。 付款人只需在账单协议建立时提供一次同意确认。 付款可以在,也可以不在设置账单协议时执行。
您可以使用 CREATE OR UPDATE TOKEN 操作对 PayPal 账单协议 ID 进行令牌化。 在 CREATE OR UPDATE TOKEN 请求 URL 中提供您的令牌 ID。
测试您的集成
有关测试集成的一般详细信息,请参阅每个适用集成方法中的测试说明。 要专门测试网关 Tokenization,使用您的测试商家配置文件。
当您的 PSP 为您启用并配置令牌化时,网关会为您的测试和生产商家配置文件创建单独的令牌库。
当您使用测试商家配置文件向网关提交令牌化请求时,网关将使用测试令牌库。 要使用令牌创建和测试付款,首先对支持的测试卡号进行令牌化,然后在后续的付款操作中使用创建的令牌。 有关测试卡的详细信息,请参阅测试卡。