我目前正在研究 Cybersource 的用于卡片标记化的 REST API。
参考：https ://developer.cybersource.com/api-reference-assets/index.html#token-management
但是，我在理解以下内容时遇到了一些麻烦，可以参考那些已经使用过 Cybersource 并且更熟悉该术语的人的一些建议。
在令牌管理下，有一个工具标识符和支付工具。工具标识符似乎为同一张卡返回相同的唯一 ID，并且是整个支付工具令牌的一部分。
如果我在响应中发布（创建）支付工具令牌，我也会看到返回工具标识符并返回相同的 ID，只要卡是相同的。但是，支付工具总是返回一个新的令牌。
问题：我试图将支付工具视为一种支付方式，对卡进行标记，而不是每次支付，但由于即使我放入同一张信用卡，它每次都会返回不同的标记，我理解错了吗？我应该将支付工具视为完全不同的东西吗？如果我要在我们这边存储一个令牌，我会是哪个？
至于支付 API，我们可以传入一个令牌，这对上述两种类型都有效吗？
任何帮助，指导或想法表示赞赏
Cybersource 从不擅长 API 设计或文档。但他们关于这个主题的文档可以帮助您理解这个概念 https://developer.cybersource.com/api/developer-guides/dita-tms/paymentInstrumentREST.html
看第一张图表。
“客户”具有与“卡”相关联的“支付工具”，该“卡”可以具有多个工具标识符，每个标识符都与特定卡号进行一对一的映射。
存在此模型是因为消费者可以使用不同的卡号或过期日期更新相同的卡。（“支付工具”试图代表它的“相同性”部分。）
因此 Cybersource 的“支付工具”模型可以看作是一个“抽象”卡对象/容器，代表工作“工具”（这就是它不存储号码的原因），它知道应该使用的实际卡号（但商户不需要知道），同时，它知道卡的“历史”。
命名很糟糕，“支付工具”本身有一个 ID，然后工具标识符 ID 也是一个“ID”（猜猜想出这个名字的人忘记 ID 是“标识符”的首字母缩写词？哈哈）。确实很混乱。请记住，仪器标识符 ID 映射到卡号，“支付工具”ID 是一个容器，它映射到一系列（相同）卡号（可能）
这样就回答了您的问题，为什么您每次都可以获得不同的“支付工具”ID，因为您可以将其视为不同的商家对于使用该实体卡的同一客户具有不同的“支付工具”ID。只要 Cybersource 有记录并且知道如何通过这个“支付工具 ID”找到相关的工具标识符 ID，它就完成了任务。
你再次知道 Cybersource 是一只生活在过去的恐龙，所以你必须处理它
因此，我对其工作原理的理解是，支付工具是一种支付类型（ACH、信用卡、比特币、ApplePay™、GooglePay™ 等），然后工具标识符是代表特定帐户的令牌（或 ID）该付款类型中的号码。
因此，信用卡的支付工具可能具有 Visa 帐户的工具标识符，4242424242424242但令牌管理服务( TMS ) 返回的工具标识符为AA7D990C34583376EB05345443E0234242434B。TMS允许将相关信息存储在客户标识符（即“钱包”所有者）中。随着TMS功能变得更加丰富，可能会添加诸如“运输信息”和其他可能的“偏好”之类的内容。另一个概念是这个数字钱包（TMS 令牌 API）可以将其权限授予其他商家实体，以便所有支付处理和交易都可以通过一个（OMNICHANEL) API 和此支付信息可以保持安全、可审计、已批准、已撤销等。
现在，您可以为同一工具获得不同“令牌”的原因是基于偏好。这意味着如果持卡人不想“将付款信息存档”或“存储令牌以备后用”。然后TMS系统会提供一个token一次性使用，从而满足商户的需求（减少PCI范围/风险）并保持持卡人的偏好。
这绝不是官方解释，因此我绝对愿意接受有关TMS（来自 Cybersource™）如何设计工作的任何其他见解。