存档凭据交易
以下各部分介绍如何将持卡人发起交易和商家发起交易（CIT 和 MIT）提交到 Mastercard Gateway，以遵守处理这些交易的卡组织标准：
- 持卡人发起的付款：
- 商家发起的付款：
有关上述场景的一般信息，请参阅持卡人发起付款与商家发起付款。 如需查看所有场景的请求的完整示例，请下载 Postman 集合。
每当您提交一系列付款时，第一个交易必须是 CIT，以获得持卡人对整个付款系列的批准。 后续交易通常都是 MIT。 在所有请求中，您都可以使用 transaction.source 字段来标识交易是由持卡人还是商家发起的，并使用 sourceOfFunds.provided.card.storedOnFile 字段来指示是否要存储付款详细信息、是否已存储付款详细信息，或者您打算存储它们。 有关详细信息，请参见常见问题。
- 从 API v74 开始支持上述场景。
- 要能够提交任何 MIT，您的 Your payment service provider (PSP) 必须在您的商家收单行链接上支持 MERCHANT 作为允许的交易来源。
- 如果您想要在网关中存储付款人的付款详细信息，然后使用令牌来引用存储的详细信息，您的 PSP 必须为商家配置文件配置网关令牌化。
一般 CIT
CIT 交易可以是一次性付款，通常您不会存储付款人提供的付款详细信息。 但是，付款人可以同意您存储他们的付款详细信息以供将来使用（通常作为客户注册或账户创建流程的一部分），以便您可以使用存储的付款详细信息提供后续的持卡人发起交易。
- 在与新客户的初始交易请求中，您需要提供以下字段：
sourceOfFunds.type = CARD或SCHEME_TOKEN值取决于您提供原始卡详细信息还是令牌（已经令牌化的卡详细信息）。
sourceOfFunds.provided.card.*字段或sourceOfFunds.tokentransaction.source = INTERNET该值向网关表明该交易是由持卡人发起的。 您可以将此值设置为
INTERNET、MOTO、MAIL_ORDER、TELEPHONE_ORDER、VOICE_RESPONSE或CALL_CENTER。sourceOfFunds.provided.card.storedOnFile = TO_BE_STORED此值指示付款人同意您存储他们的付款详细信息供将来使用。
INTERNET 值。 但您应该注明您收到付款的渠道。在付款人（而非您）发起的任何后续付款中，如果使用了付款人的已存储付款详细信息，您必须在请求中提供以下字段：
-
sourceOfFunds.type = CARD或SCHEME_TOKEN值取决于详细信息是由您存储还是由网关存储（在这种情况下您提供令牌）。
-
sourceOfFunds.provided.card.*字段或sourceOfFunds.token -
transaction.source = INTERNET -
sourceOfFunds.provided.card.storedOnFile = STORED
有关如何向网关指示存储详细信息如何以及是否存储的更多详细信息，请参见常见问题。
使用 3DS 的 CIT
可以使用 3DS 验证 CIT，以识别持卡人并防止欺诈。 您可以在以下交易中使用 3DS：
- 一次性 CIT
- CIT 是一系列付款的第一步，后续付款是 MIT
- 您希望在将持卡人卡添加到客户账户以供将来使用时对持卡人进行身份验证的场景
下表描述了与 3DS 身份验证相关的一些详细用例。 有关网关中的 3DS 身份验证以及在付款交易中使用外部授权的更多信息，请参阅 3DS 身份验证。
| 使用案例 | 集成步骤 |
|---|---|
与付款人达成的定期付款协议，包括 CIT 的初始费用 |
步骤 1： 按照身份验证指南中的说明执行 Authentication，并指定初始付款所需的金额。 步骤 2： 使用持卡人发起付款部分定义的详细信息创建 CIT 请求，并添加以下内容之一：
|
|
与付款人达成的定期付款协议，不包括 CIT 的初始费用 |
此用例包括付款人注册服务时没有到期付款的定期付款系列。 按照 3DS 身份验证主题中所述执行身份验证时，使用以下步骤中指定的其他字段来集成 3DS 以进行定期付款。 步骤 1： 执行 INITIATE AUTHENTICATION 操作，将 authentication.purpose 设置为 ADD_CARD 或 MAINTAIN_CARD。 步骤 2： 执行包含以下字段的 AUTHENTICATE PAYER 操作：
步骤 3： 对于 CIT 请求，执行 VERIFY 操作请求并添加以下内容之一：
如果您正在使用 Hosted Session 集成，请在会话中完成步骤 1 和 2，然后在步骤 3 从您的服务器发送请求时使用会话 ID（来自为步骤 1 和 2 创建的会话）。
|
|
添加卡（不建立付款协议） |
此用例介绍的场景：付款人想要在您这里创建个人资料或客户账户时添加卡详细信息，没有任何即时付款。 付款人可以在将来使用存储的卡进行一次性付款，或者为一系列付款建立付款协议。 步骤 1： 执行 INITIATE AUTHENTICATION 操作，将 authentication.purpose 设置为 ADD_CARD 或 MAINTAIN_CARD。 步骤 2： 执行 AUTHENTICATE PAYER 操作，将金额设置为 0。 步骤 3： 对于 CIT 请求，执行 VERIFY 操作请求并添加以下内容之一：
如果您正在使用 Hosted Session 集成，请在会话中完成步骤 1 和 2，然后在步骤 3 从您的服务器发送请求时使用会话 ID（来自为步骤 1 和 2 创建的会话）。
|
AUTHENTICATE PAYER 操作中需要以下字段来成功完成重复交易：
- 使用 API v61 或更高版本时：
- agreement.id
- agreement.type=RECURRING
- agreement.numberOfPayments
- agreement.amountVariability
- agreement.expiryDate
- agreement.paymentFrequency
- agreement.minimumDaysBetweenPayments
使用 API v57 - v60 时：
- agreement.id
- agreement.type=RECURRING
- agreement.expiryDate
- agreement.recurring.daysBetweenPayments
使用 Hosted Checkout 和存储凭据的 CIT
当不存在存储凭据时，使用 Hosted Checkout 创建 CIT：
- 发送包含
interaction.saveCardForCredentialOnFile = PAYER_INITIATED_PAYMENTS的 INITIATE CHECKOUT 操作请求。Hosted Checkout 在付款选项窗口中为付款人提供可用的付款选项。
- 从 API v74 开始，支持在 Hosted Checkout 场景中使用存档凭据。
- 如果您支持 Click to Pay 付款方式，Hosted Checkout 不会在付款页面单独显示存档凭据。 付款人会被要求提供电子邮件地址，如果付款人有 Click to Pay 个人资料，他们在个人资料中存储的卡会在“借记卡或信用卡”部分列出。
- 付款人选择借记卡或信用卡。
Hosted Checkout 不会显示或链接到“条款和条件”或“隐私政策”。 您有责任根据任何监管法规或隐私法的要求向付款人提供这些详细信息 - 付款人可以在向网关提供或不提供同意的情况下进行支付，即选择或不选择保存此卡在将来购物时使用复选框。
- 如果付款人未表示同意而继续支付，则付款流程照常进行。
- 如果付款人提供同意确认并继续支付，则 Hosted Checkout：
- 设置正确的存档卡指示器
- 使用
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED和transaction.payerConsentForStoringCardDetails=PAYER_INITIATED_PAYMENTS提交 PAY（如果interaction.operation=AUTHORIZE) 交易请求。
您必须遵守组织和监管要求（例如，GDPR）。 您必须向付款人提供取消同意并删除网关令牌的选项。
如果付款人使用信用卡以外的方式付款，如 ACH (Automated Clearing House) 或 PayPal，则适用标准结账程序。 网关仅存储卡详细信息，因此如果您想存储与其他付款方式相关的任何付款详细信息，您必须在获得付款人的同意后自行执行。 - 网关将付款人返回到您商店的网站后，提交
RETRIEVE_ORDER操作请求。- 如果付款人已提供同意确认，响应将包含
transaction.payerConsentForStoringCardDetails=PAYER_INITIATED_PAYMENTS字段。 - 要创建可用于引用网关中存储的凭据的令牌，使用 CREATE OR UPDATE TOKEN 操作。 有关更多详细信息，请参阅网关令牌化。
- 如果付款人已提供同意确认，响应将包含
- 对于任何后续的持卡人发起付款，发送包含以下字段的 INITIATE CHECKOUT 操作请求：
interaction.tokens包含网关令牌interaction.saveCardForCredentialOnFile=PAYER_INITIATED_PAYMENTS此字段允许付款人输入新的卡详细信息并存储（如果他们不想使用之前的信息）。
Hosted Checkout 向付款人显示可用付款选项和存储的卡。
- 如果付款人选择借记卡或信用卡，将列出令牌的详细信息，付款人可以选择使用令牌支付或添加另一张卡的详细信息。
使用 Hosted Checkout 向 MIT 授权的 CIT
要从使用 Hosted Checkout 的付款人处收集同意确认，以存储后续 MIT 的付款详细信息（例如，在您的系统中创建付款人账户并为该账户存储详细信息）：
- 发送 INITIATE CHECKOUT 操作请求，包含以下字段：
agreement.id由您生成的唯一值，用于识别与付款人的付款协议。 您需要在后续的 MIT 上提交它，以将一系列付款链接起来。 这是卡组织规定的必要操作，在这里，协议 ID 作为将之前的 CIT 链接到后续的 MIT 的标识符。
agreement.type与付款人建立的商业协议类型。
- 从 API v74 开始，支持在 Hosted Checkout 场景中使用存档凭据。
- 只有当您打算以后再处理与 CIT 相关的 MIT 时才需要协议详细信息。 如果您只打算使用存储的付款详细信息处理 CIT，则无需建立协议。
Hosted Checkout 会为付款人提供借记卡或信用卡付款选项。
- 您必须遵守组织和监管要求，例如，GDPR。 您必须向付款人提供取消同意和删除存储凭据的选项。
- 您负责确保订单或交易中不包含不需要协议的商品。
- 付款人只有在同意（即选中复选框）的情况下才能继续操作。 在选中复选框前，付款按钮一直是禁用状态。
如果付款人确认同意，继续操作，Hosted Checkout 将提交具有以下值的交易请求：
sourceOfFunds.provided.card.storedOnFile = TO_BE_STOREDtransaction.payerConsentForStoringCardDetails = MERCHANT_INITIATED_PAYMENTS
- 网关将付款人返回到您的网站后，提交 RETRIEVE ORDER 操作请求：
- 如果付款人已提供同意确认，响应将包含
transaction.payerConsentForStoringCardDetails = MERCHANT_INITIATED_PAYMENTS字段。 - 如果付款人没有提供同意确认，付款人无法继续（购物车被放弃）。
- 如果付款人已提供同意确认，响应将包含
商家发起的定期付款
如果付款人同意您存储他们的付款详细信息以供将来使用，并且您与付款人达成了付款协议，授权您在没有付款人主动参与的情况下发起后续的定期付款，您可以向网关提交定期付款以进行处理。
在初始 CIT 请求中，您需要提供以下字段来设置协议：
sourceOfFunds.type=CARD或SCHEME_TOKEN值取决于您提供原始卡详细信息还是令牌（已经令牌化的卡详细信息）。
sourceOfFunds.provided.card.*字段或sourceOfFunds.tokentransaction.source=INTERNET, and该值向网关表明该交易是由持卡人发起的。
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED此值指示付款人同意您存储他们的付款详细信息供将来使用。
agreement.id由您生成的唯一值，用于识别与付款人的付款协议。
agreement.type=RECURRING您与付款人建立的常备指令协议。
- 使用 API v61 及更高版本时：
agreement.numberOfPaymentsagreement.amountVariabilityagreement.expiryDateagreement.paymentFrequencyagreement.minimumDaysBetweenPayments
- 使用 API v57 - v60 时：
agreement.expiryDateagreement.recurring.daysBetweenPayments
在任何后续 MIT 请求中，您必须提供以下字段：
sourceOfFunds.type=CARD或SCHEME_TOKEN值取决于详细信息是由您存储还是由网关存储（在这种情况下您提供令牌）。
sourceOfFunds.provided.card.*字段或sourceOfFunds.tokentransaction.source=MERCHANT值向网关表明该交易是由商家发起的。
sourceOfFunds.provided.card.storedOnFile=STOREDagreement.id值必须与初始 CIT 交易中提供的 agreement.id 相同。 这样，网关可以将一系列付款链接起来，这是卡组织规定的操作，这时，协议 ID 将作为链接之前的 CIT 与后续 MIT 的标识符。
商家发起的分期付款
如果付款人同意您存储他们的付款详细信息以供将来使用，并且您与付款人达成付款协议，将单笔购买分成按约定的时间间隔处理的多笔付款，则可以向网关提交分期付款进行处理。
在初始 CIT 请求中，您需要提供以下字段来设置协议：
sourceOfFunds.type=CARD或SCHEME_TOKEN值取决于您提供原始卡详细信息还是令牌（已经令牌化的卡详细信息）。
sourceOfFunds.provided.card.*字段或sourceOfFunds.tokentransaction.source=INTERNET该值向网关表明该交易是由持卡人发起的。
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED此值指示付款人同意您存储他们的付款详细信息供将来使用。
agreement.id由您生成的唯一值，用于识别与付款人的付款协议。
agreement.type=INSTALLMENT您与付款人建立的常备指令协议。
- 使用 API v61 及更高版本时：
agreement.numberOfPaymentsagreement.amountVariabilityagreement.expiryDateagreement.paymentFrequencyagreement.minimumDaysBetweenPayments
- 使用 API v57 - v60 时：
agreement.expiryDateagreement.recurring.daysBetweenPayments
在任何后续 MIT 请求中，您必须提供以下字段：
sourceOfFunds.type=CARD或SCHEME_TOKEN值取决于详细信息是由您存储还是由网关存储（在这种情况下您提供令牌）。
sourceOfFunds.provided.card.*字段或sourceOfFunds.token值向网关表明该交易是由商家发起的。
transaction.source=MERCHANTsourceOfFunds.provided.card.storedOnFile=STOREDagreement.id值必须与初始 CIT 交易中提供的
agreement.id相同。 这样，网关可以将一系列付款链接起来，这是卡组织规定的操作，这时，协议 ID 将作为链接之前的 CIT 与后续 MIT 的标识符。
商家发起的计划外付款
如果付款人同意您存储他们的付款详细信息以供将来使用，并且您与付款人达成了付款协议，授权您在没有付款人主动参与的情况下发起后续的计划外付款，您可以将计划外付款提交网关进行处理。
在初始 CIT 请求中，您需要提供以下字段来设置协议：
sourceOfFunds.type=CARD或SCHEME_TOKEN值取决于您提供原始卡详细信息还是令牌（已经令牌化的卡详细信息）。
sourceOfFunds.provided.card.*字段或sourceOfFunds.tokentransaction.source=INTERNET该值向网关表明该交易是由持卡人发起的。
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED此值指示付款人同意您存储他们的付款详细信息供将来使用。
agreement.id由您生成的唯一值，用于识别与付款人的付款协议。
agreement.type=UNSCHEDULED您与付款人建立的常备指令协议。
- 使用 API v61 及更高版本时：
agreement.numberOfPaymentsagreement.amountVariabilityagreement.paymentFrequency
- 使用 API v57 - v60 时：
agreement.expiryDateagreement.recurring.daysBetweenPayments
在任何后续 MIT 请求中，您必须提供以下字段：
sourceOfFunds.type=CARD或SCHEME_TOKEN值取决于详细信息是由您存储还是由网关存储（在这种情况下您提供令牌）。
sourceOfFunds.provided.card.*字段或sourceOfFunds.tokentransaction.source=MERCHANT值向网关表明该交易是由商家发起的。
sourceOfFunds.provided.card.storedOnFile=STOREDagreement.id: 与初始交易中提供的 agreement.id 相同。 这允许网关关联一系列的付款。值必须与初始 CIT 交易中提供的 agreement.id 相同。 这样，网关可以将一系列付款链接起来，这是卡组织规定的操作，这时，协议 ID 将作为链接之前的 CIT 与后续 MIT 的标识符。
商家发起的行业惯例付款
如果付款人允许您存储他们的付款详细信息以供将来使用，并授权您在没有付款人主动参与的情况下发起后续 MIT，您可以将行业惯例付款提交到网关进行处理。
在行业惯例 MIT 请求中，您需要提供以下字段：
order.industryPracticePaymentReason您正在创建的行业付款类型，例如 DELAYED_CHARGE、NO_SHOW_PENALTY 或 PARTIAL_SHIPMENT。
sourceofFunds.provided.card.storedOnFiles = STORED此值指示付款人已同意您存储他们的付款详细信息供将来使用。
referenceOrderId来自上一个 CIT 的订单 ID。网关使用此字段查找上一个 CIT 的跟踪 ID。
transaction.acquirer.traceid跟踪 ID。 此字段包含付款系列中初始 CIT 的响应中的 authorizationResponse.transactionIdentifier。 仅当参考订单 ID 不可用时才需要此字段。 如果您提供协议 ID，但未提供 Mastercard 交易卡上的参考订单 ID 或跟踪 ID，网关将提供默认的网关跟踪 ID。
行业惯例流示例
初始 CIT：
order.id=“OD12345”transaction.id=“TRAN 1”agreement.id ==“AGR 1”sourceOfFunds.type=CARD或SCHEME_TOKENsourceOfFunds.provided.card.*字段或sourceOfFunds.tokentransaction.source=INTERNETsourceOfFunds.provided.card.storedOnFile=TO_BE_STORED
由于延迟收费，作为新订单提交的后续行业惯例 MIT：
order.id="OD45678"transaction.id=“TRAN 2”agreement.id ==“AGR 1”sourceOfFunds.type=CARD或SCHEME_TOKENsourceOfFunds.provided.card.*字段或sourceOfFunds.tokentransaction.source=MERCHANTsourceOfFunds.provided.card.storedOnFile=STOREDorder.industryPracticePaymentReason=DELAYED_CHARGEreferenceOrderId="OD12345"
商家发起的重新提交付款
如果付款人同意您存储他们的付款详细信息以供将来使用，并且发卡机构对失败付款的响应不禁止您稍后重试，您可以将失败的付款重新提交到网关进行处理。
在 MIT 重新提交请求中，您需要提供以下字段：
order.id如果重新提交 MIT，请使用与第一个 MIT 相同的订单 ID，但使用新的 transaction.id，因为网关不允许在同一订单中出现重复的交易 ID。
transaction.resubmission = "true"表明此 MIT 是针对先前失败的授权的重新提交。
referenceOrderId来自上一个 CIT 的订单 ID。网关使用此字段查找上一个 CIT 的跟踪 ID。
- 如果之前的 CIT 是在网关外进行的，您应该提供：
transaction.acquirer.traceid跟踪 ID。 此字段包含付款系列中初始 CIT 的响应中的
authorizationResponse.transactionIdentifier。 仅当没有参考订单 ID 时需要此字段。 - 如果您提供协议 ID，但未提供 Mastercard 交易卡上的参考订单 ID 或跟踪 ID，网关将提供默认的网关跟踪 ID。
重新提交流示例
初始 CIT：
order.id=“OD12345”transaction.id=“TRAN 1”agreement.id=“AGR 1”sourceOfFunds.type=CARD或SCHEME_TOKENsourceOfFunds.provided.card.*字段或sourceOfFunds.tokentransaction.source=INTERNETsourceOfFunds.provided.card.storedOnFile=TO_BE_STORED
由于延迟收费，作为行业惯例付款以新订单形式提交的第一个 MIT：
order.id="OD5678"transaction.id=“TRAN 2”sourceOfFunds.type=CARD或SCHEME_TOKENsourceOfFunds.provided.card.*字段或sourceOfFunds.tokentransaction.source=MERCHANTsourceOfFunds.provided.card.storedOnFile=STOREDorder.industryPracticePaymentReason=DELAYED_CHARGEreferenceOrderId="OD12345"
第一个 MIT 由于资金不足失败后，第二个 MIT 将作为重新提交发送（同一订单）：
order.id="OD5678"transaction.id=“TRAN 3”sourceOfFunds.type=CARD或SCHEME_TOKENsourceOfFunds.provided.card.*字段或sourceOfFunds.tokentransaction.source=MERCHANTsourceOfFunds.provided.card.storedOnFile=STOREDorder.industryPracticePaymentReason=DELAYED_CHARGEtransaction.resubmission="true"
常见问题
我如何向网关指示付款详细信息是如何处理的？
为了遵守处理 CIT 和 MIT 的卡组织标准，您必须使用 sourceOfFunds.provided.card.storedOnFile 字段向网关指示是否已存储、未存储还是打算存储付款详细信息。
对于初始 CIT：
- 如果是一次性付款并且您不打算存储付款详细信息，忽略请求中的
sourceOfFunds.provided.card.storedOnFile字段。 -
如果这是付款人在您这里的第一笔交易，其付款详细信息之前没有存储过，但您现在打算存储这些信息以供将来使用，设置
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED。 这向网关指示付款人已同意您存储其付款详细信息。 您必须设置此值，无论： - 如果付款人是返回客户，您之前已经为其他订单存储了他们的付款详细信息，您无需再次存储他们的付款详细信息。 但是，如果您使用新的 CIT 与付款人创建与此 CIT 相关的未来 MIT 的协议，请设置
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED。 这会指示网关您将在未来的 MIT 交易中使用这些详细信息。
对于后续付款，设置 sourceOfFunds.provided.card.storedOnFile=STORED 来指示付款中使用存档凭据。 这也适用于付款人返回，其存储的付款详细信息用于新 CIT（未来的 MIT 不需要新协议）的情况。
如果我没有协议 ID 怎么办？
如果您与付款人之间的协议没有唯一标识符，您可以：
- 生成协议 ID 以与网关进行交互。 然后，您必须存储此 ID 并在付款系列的所有付款（包括 CIT）中将其提交到网关。
- 使用现有标识符（您已经存储在系统中），例如，系列中第一个付款的订单 ID。
如果可能，应始终使用协议 ID，它是您与付款人之间的特有示值。 例如，如果付款人需要续保，则协议 ID 可以是保单号。
在某些情况下，您可能无法访问原始协议 ID。 例如：
- 协议建立已久，并且记录中没有保留详细记录。
- 您不知道初始协议 ID 或者它是在另一个支付网关中创建的。
在这些情况下，您无法生成新的协议 ID，而需要使用参考订单 ID 或跟踪 ID。
参考订单 ID 反映交易系列中的最新订单。 例如，如果交易系列由初始 CIT 和 2 个后续 MIT 组成：
- 初始 CIT 的订单 ID = 1
- 第一个 MIT 的订单 ID = 2，使用参考订单 ID = 1（因为引用初始 CIT）
- 第二个 MIT 的订单 ID = 3，使用参考订单 ID = 2（因为它引用第一个 MIT，即该系列中的最新订单 ID）
跟踪 ID（也称为组织交易 ID）是所有组织为通过该组织处理的每笔交易发出的唯一标识符。 跟踪 ID 用于识别相关交易，例如：
- 后续 CAPTURE 交易
- 撤消交易
- 关联的 REFUND AUTHORIZATION 交易
- 重复、分期或计划外付款系列的后续交易
- 要更新的 AUTHORIZATION
各组织使用不同的方法生成此 ID：
- Mastercard 生成包含以下内容的 ID：
- 3 位数金融网络代码
- Banknet 参考号 (AN6)
- 交易日期 (MMDD)
- VISA 为每笔原始交易生成一个唯一的 ID。
- Amex 会为每笔原始交易生成一个唯一的 ID。
建立付款协议时，我是否需要提交付款？
否。如果在与付款人建立付款协议时，您不打算对付款人扣款，例如，进行杂志订阅，计划在 30 天后首次付款，您必须提交包含协议详细信息的 VERIFY 请求：
agreement.idagreement.type
Verify 交易成为系列中的第一个 CIT。 对于任何后续付款，请使用 agreement.id 关联系列中的付款。
如果付款人已使用 3DS 身份验证在网关中完成了身份验证，您可以在 VERIFY 请求中提供网关身份验证结果中的 authentication.transactionId，来将身份验证信息链接到付款协议。 对于进行外部身份验证的交易，请参阅 3DS 身份验证的常见问题。
如果协议的付款详细信息发生变化会怎样？
协议的付款详细信息可能会在某些情况下发生变化，例如：
- 付款人的卡丢失，申领了一张新卡。
- 付款人更换了银行。
- 卡内资金不足，付款人提供了其他付款详细信息
如果卡详细信息有变动（重新发放过期卡和网络令牌除外），您必须先使用原始协议 ID 执行 CIT 来更新付款详细信息或网关令牌，然后再使用新卡号执行 MIT。 根据您的业务模型，您还可以决定与付款人创建新协议。
如果您使用网络令牌化，组织可以自动更新在网关中为网络令牌存储的卡号。