存档凭据、持卡人发起交易和商家发起交易
本页内容介绍如何将持卡人发起交易和商家发起交易提交到网关,以遵守处理这些交易的卡组织标准。
您可能实现了某项集成,可以从付款人那里收集付款详细信息、存储这些信息,然后使用这些信息处理付款人的未来付款。 如果是这样,请在初始交易中,向您存储付款详细信息并打算将来使用这些信息的网关提供信息。 当您使用存储的付款详细信息执行后续付款时,也必须将这些信息提供给网关,不论付款是由付款人发起(持卡人发起交易)还是您根据与付款人的协议作为商家发起(商家发起交易)。
这是为了遵守使用存储的付款详细信息(也称为存档凭据 (COF) 要求)处理持卡人发起付款和商家发起付款的卡组织标准。 将信息提交到网关来识别存储的付款详细信息、持卡人发起交易和商家发起交易,可以提供:
- 发卡机构可以更清楚地了解交易风险水平
- 授权批准率更高,完成的销售更多,以及
- 改善付款人体验。
从 WS API v74 开始,网关支持使用存储的付款详细信息进行以下付款:
存档的 3D 验证凭据
您可以将 3D 验证用于持卡人发起付款。 更多信息请阅读以下具体详细信息。
执行持卡人发起付款
持卡人发起交易是通过付款人的主动参与执行的交易。 例如,电子商务、邮购或电话订单交易。
为了指示交易是由付款人发起的,您必须将 transaction.source
设置为 INTERNET
/MOTO
/MAIL_ORDER
/TELEPHONE_ORDER
/VOICE_RESPONSE
/CALL_CENTER
。 在本指南中,我们使用网络支付 (transaction.source
=INTERNET
) 来说明持卡人发起交易;不过,您可以将它更改为允许的任何其他值。
持卡人发起交易可能是一次性付款,您通常不会存储付款人提供的付款详细信息。 不过,您可以与付款人签订协议来存储其付款详细信息以备将来使用(通常作为客户注册或账户创建流程的一部分),然后使用存储的付款详细信息执行后续的持卡人发起交易。
如果在付款人交互期间,付款人同意您存储其付款详细信息以备将来使用,您需要在初始交易中提供以下字段:
sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=INTERNET, and
sourceOfFunds.provided.card.storedOnFile
:TO_BE_STORED.
对于付款人(不是您)发起的以及使用存储的付款人付款详细信息的后续付款,您必须提供:
sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=INTERNET, and
sourceOfFunds.provided.card.storedOnFile
:STORED.
有关如何向网关指示付款详细信息已存储、未存储或打算存储的信息,请参见常见问题。
执行商家发起付款
商家发起交易是使用存储的付款详细信息但不通过付款人主动参与执行的交易。 如果您提供的是以下产品或服务,您可能在执行商家发起交易:
协议数据用例
- 重复付款 - 需要您使用预定义的时间表向付款人收费的产品或服务。例如,杂志订阅或健身房会员资格的后续重复付款。
- 分期付款 - 付款人通过分期付款支付一次购物的费用。
- 充值 - 向付款人提供按需对服务收费的服务。 例如,当可用金额低于定义的阈值时,为账户充值。
在前面的用例中,您需要与付款人就这些服务签订协议。 付款人必须为此同意您存储其付款详细信息,并允许您之后在没有其主动参与的情况下使用存储的付款详细信息发起付款。
行业惯例付款用例
- 相关/延迟费用 - 初始服务付款处理完毕后的其他账户费用。 例如,持卡人在酒店退房后额外支付的迷你酒吧费用。
- 缺席处罚 - 根据商家的取消政策向付款人收取的罚款。 例如,持卡人在未适当提前通知商家的情况下取消预订。
- 部分发货 - 由于各种原因(如缺货、商品涉及多家供应商等),商家决定将同一订单的商品分多次发货的发货情形。 例如,供应商不能提供所有商品或物流服务。
重新提交付款用例
- 重新提交 - 之前尝试获取交易授权被拒绝,但发卡机构的响应不禁止商家稍后重试,即使付款人不在位。 例如,资金不足。
协议详细信息
当您与付款人签订允许您后续提交商家发起付款的协议时,您必须在系列的初始交易(即持卡人发起交易)中提供以下协议详细信息:
agreement.id
: 指定您生成的用于识别与付款人之间的付款协议的唯一值。 您还需要在后续的商家发起交易中提交此值来关联一系列付款。 在将协议 ID 作为先前的持卡人发起交易与后续的商家发起付款关联的标识符时,这是遵守卡组织要求的必需操作。agreement.type
: 指示与付款人之间的商业协议是否已确立。 您只需在与付款人建立协议时(即在持卡人发起交易中)提供此信息。
行业惯例付款详细信息和重新提交详细信息
当您与付款人签订协议,允许商家后续提交商家发起的行业惯例付款时,商家需要提供以下详细信息:
order.industryPracticePaymentReason
- 此字段用于对在某些行业惯例背景下提交的商家发起付款进行分类。 使用此字段指示该行业惯例付款的原因。 例如,DELAYED_CHARGE、NO_SHOW_PENALTY 或 PARTIAL_SHIPMENT。sourceofFunds.provided.card.storedOnFiles = STORED
- 此字段指示商家在提交行业惯例交易之前必须获得的付款人的同意。transaction.resubmission
- 此字段指示此商家发起的交易是对之前因资金不足导致失败的授权的重新提交。 重新提交的操作只能是 Authorize 或 Pay。referenceOrderId
- 此字段指示您之前向网关提交的订单的引用。 适用于提交付款交易的以下场景:- 行业惯例付款: 这是对初始持卡人发起交易的引用。
- 重新提交交易: 这是对商家发起的正在重新提交的交易的引用。
行业惯例付款详细信息和重新提交详细信息 API 参考 [REST][NVP]
交易来源
提交付款时,您需要区分系列中的第一个交易(即持卡人发起交易)和系列中后续的所有商家发起付款。 您可以使用 transaction.source
字段实现此目的,对于初始交易,必须设置 transaction.source
=INTERNET
或任何其他允许的值以指示交易是由付款人发起的。 对于系列中的后续付款,您必须设置 transaction.source
=MERCHANT
来指示交易是由您发起的。Your payment service provider 必须在您的商家收单行链接上启用“MERCHANT”作为允许的交易来源。
当您提交系列中的第一个持卡人发起交易或后续的商家发起付款时,您必须向网关指示是否已存储、未存储还是打算存储付款详细信息。 有关详细信息,请参见常见问题。
重复付款
重复付款是付款人授权您按照协定的时间间隔(例如,每周、每月)处理周期性账单或发票的付款的协议。
如果您与付款人之间有付款协议,付款人同意您存储他们的付款详细信息以备将来使用,并授权您在没有其主动参与的情况下发起后续的重复付款,您可以将重复付款提交到网关处理。
为此,您需要在一个交易系列的初始交易中提供以下字段:
sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=INTERNET, and
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
agreement.id
agreement.type
=RECURRING
对于您发起的一系列后续付款,必须提供
sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED, and
agreement.id
: 与初始交易中提供的 agreement.id 相同。 这允许网关关联一系列的付款。
对付款人进行身份验证
下表中指定了使用持卡人发起付款处理 3DS 支付验证的不同场景或用例。 有关 3DS 支付验证的更多信息,请参阅 3D 验证集成指南。
对于外部授权交易,请参阅身份验证指南。
在版本 61 请求中使用 WS API AUTHENTICATE_PAYER 时,需要提供以下字段来成功处理重复交易:
- agreement.id
- agreement.type=RECURRING
- agreement.numberOfPayments
- agreement.amountVariability
- agreement.expiryDate
- agreement.paymentFrequency
- agreement.minimumDaysBetweenPayments
在版本 57-60 请求中使用 WS API AUTHENTICATE_PAYER 时,需要提供以下字段来成功处理重复交易:
- agreement.id
- agreement.type=RECURRING
- agreement.expiryDate
- agreement.recurring.daysBetweenPayments
使用案例 | 集成步骤 |
---|---|
与付款人建立包括初始费用在内的重复协议,然后发起一系列新的重复付款。 |
|
在最初没有付款到期时建立重复付款系列 如果您想要在付款人注册服务时没有到期付款的情况下与付款人建立重复付款系列。 示例: 每月订阅服务,客户在注册时无需付款。 |
参考身份验证指南时,使用以下步骤中指定的这些参数来集成用于重复付款的 3DS。 步骤 1 和 2 必须在持卡人在会话期间完成。 步骤 3 应在您准备好处理付款时执行。
当持卡人在会话中时,完成步骤 1 和 2。当您准备好处理付款时,执行步骤 3。 步骤 1: 发起身份验证
步骤 2: 对付款人进行身份验证
步骤 3: 执行验证操作,然后选择以下选项之一:
或
|
在不建立付款协议的情况下添加卡 如果您希望为付款人提供一个选项,来在注册时不建立付款协议的情况下在创建个人资料或账户时添加卡详细信息。 添加的卡可以在将来使用。 |
参考身份验证指南时,使用以下步骤中指定的这些参数来集成 3DS。 步骤 1: 发起身份验证
步骤 2: 对付款人进行身份验证
|
执行商家发起的分期付款
分期付款是付款人授权将单笔购买的付款拆分成按协定的时间间隔处理的多笔付款的协议。 例如,按六个月分期支付购买商品的款项。
如果您与付款人之间有付款协议,付款人同意您存储他们的付款详细信息以备将来使用,并授权您在没有其主动参与的情况下发起后续的分期付款,您可以将分期付款提交到网关处理。
为此,您需要在一个交易系列的初始交易中提供以下字段:
sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=INTERNET
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
agreement.id, and
agreement.type
=INSTALLMENT
对于您发起的一系列后续分期付款,必须提供:
sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED
agreement.id
: 与初始交易中提供的 agreement.id 相同。 这允许网关关联一系列的付款。
执行商家发起的计划外付款
计划外付款是付款人授权商家在需要时(计划外)自动扣除协定购买款项的资金的协议。 例如,当账户值低于限值时自动充值。
如果您与付款人之间有付款协议,付款人同意您存储他们的付款详细信息以备将来使用,并授权您在没有其主动参与的情况下发起后续的计划外付款,您可以将计划外付款提交到网关处理。
为此,您需要在一个交易系列的初始交易中提供以下字段:
sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=INTERNET
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
agreement.id, and
agreement.type
=UNSCHEDULED
对于您发起的一系列后续的计划外付款,必须提供:
sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED, and
agreement.id
: 与初始交易中提供的 agreement.id 相同。 这允许网关关联一系列的付款。
执行商家发起的行业惯例付款
如果您与付款人签订了付款协议,付款人同意商家存储其付款详细信息以供将来使用,并授权您在没有付款人主动参与的情况下发起后续商家付款,您可以将在某些行业惯例背景下提交的商家发起的付款提交网关进行处理。
要实现此目的,在一个交易系列的初始交易中提供以下字段:
order.id
=“OD12345”transaction.id
=“TRAN 1”sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=INTERNET, MOTO, MAIL_ORDER, TELEPHONE_ORDER, CALL_CENTRE, or VOICE_RESPONSE
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
对于您发起的后续商家付款,提供以下字段:
order.id
="OD45678"
transaction.id
=“TRAN 2”sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED
order.industryPracticePaymentReason : {DELAYED_CHARGE, NO_SHOW_PENALTY, PARTIAL_SHIPMENT}
referenceOrderId
="OD12345"
transaction.acquirer.traceid
="MCC123456889"
transaction.relatedTransactions.firstTransactionInTheSeries.source
=MOTO, MAIL_ORDER, TELEPHONE_ORDER, CALL_CENTRE, or VOICE_RESPONSE
- referenceOrderId 提供对交易系列中初始客户发起交易中的 order.id 的引用。
- transaction.acquirer.traceid 字段与交易系列中初始客户发起交易中的 authorizationResponse.transactionIdentifier 相同。 当交易系列中的初始交易在 MPGS 网关之外成功执行时,必须提供此字段。
- 对于行业惯例付款原因“DELAYED_CHARGE”,您必须提供初始客户发起交易(系列中的初始客户发起交易已在 QNB ALAHLI 外部成功进行)中的字段 transaction.relatedTransactions.firstTransactionInTheSeries.source。 允许的枚举值有 MOTO、MAIL_ORDER、TELEPHONE_ORDER、CALL_CENTRE 或 VOICE_RESPONSE。
执行商家发起的重新提交付款
如果之前的授权付款因资金不足导致失败,您可以重新提交商家发起的付款。 重新提交的操作只能是 Authorize 或 Pay。
要实现此目的,在一个交易系列的初始交易中提供以下字段:
order.id
=“OD12345”transaction.id
=“TRAN 1”sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=INTERNET
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
对于您发起的后续商家付款,提供以下字段:
为方便起见,此部分的第一个 MIT 交易称为 MIT1,后来重新提交的 MIT 交易称为 MIT2。
对于 MIT1,提供以下字段:
order.id
="OD5678"
transaction.id
=“TRAN 2”sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED
order.industryPracticePaymentReason : {DELAYED_CHARGE, NO_SHOW_PENALTY, PARTIAL_SHIPMENT}
referenceOrderId
="OD12345"
transaction.acquirer.traceid
="MCC0987335353"
- referenceOrderId 提供对交易系列中初始客户发起交易中的 order.id 的引用。
- transaction.acquirer.traceid 字段与交易系列中初始客户发起交易中的 authorizationResponse.transactionIdentifier 相同。 当交易系列中的初始交易在 MPGS 网关之外成功执行时,必须提供此字段。
MIT 1 将因资金不足拒绝交易。 因此,商家重新提交发送的 MIT 交易,现在是 MIT2。
对于 MIT 2,提供以下字段:
order.id
="OD5678"
transaction.id
=“TRAN 3”sourceOfFunds.type
=CARD
或SCHEME_TOKEN
sourceOfFunds.provided.card.*
字段或sourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED
order.industryPracticePaymentReason : {DELAYED_CHARGE, NO_SHOW_PENALTY, PARTIAL_SHIPMENT}
transaction.resubmission
="true"
referenceOrderId
="OD12345"
transaction.acquirer.traceid
="MCC0987335353"
- referenceOrderId 提供最后一笔商家发起的因资金不足而失败的交易的 order.id。
- transaction.acquirer.traceid 字段与交易系列中初始客户发起交易中的 authorizationResponse.transactionIdentifier 相同。 当交易系列中的初始交易在 MPGS 网关之外成功执行时,必须提供此字段。
- transaction.acquirer.traceid 与交易系列中最后一笔商家发起交易的 authorizationResponse.transactionIdentifier 相同。
持卡人发起交易的 <<checkout>>
持卡人发起交易 (CIT) 的 <<checkout>> 允许您收集付款人的同意,以存储其付款详细信息用于后续付款人发起的交易。
interaction.operation=AUTHORIZE
。对 interaction.operation=PURCHASE 的其他支持即将推出。先决条件
- 确保 MSO 已为网关令牌化配置您的商家配置文件。
- 要使用存档凭据功能,必须使用 WS API v74 或更高版本。
请求 CIT 的 <<checkout>>
按照以下步骤请求 CIT 的 <<checkout>>:
- 使用
interaction.saveCardForCredentialOnFile=PAYER_INITIATED_PAYMENTS
请求 WS API INITIATE_CHECKOUT。<<checkout>> 为付款人提供可用的付款选项。
付款人的付款选项列表不包括 Click to Pay。
付款人的付款选项列表不包括 Click to Pay。 - 如果付款人选择“借记卡或信用卡”,则会显示以下“付款选项”复选框。
如果付款人使用信用卡以外的方式支付,例如 ACH 或 PayPal,则适用标准结账程序。<<checkout>> 不显示或链接到条款和条件、隐私政策或两者。 您有责任根据任何监管法规或隐私法的要求向付款人提供这些详细信息
- 付款人可以在向网关提供或不提供同意的情况下进行支付,即选择或不选择“保存此卡在将来购物时使用”复选框。
- 如果付款人未表示同意而继续支付,则付款流程照常进行。 在这种情况下,网关不会对付款人的卡进行令牌化。
- 如果付款人在表示同意的情况下继续支付,则使用 <<checkout>>;
- 设置正确的记录的卡指示器
- 使用
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED
和transaction.payerConsentForStoringCardDetails=PAYER_INITIATED_PAYMENTS
提交 AUTH(如果interaction.operation=AUTHORIZE
) 交易请求。
您必须遵守组织和监管要求(例如,GDPR)。 您必须向付款人提供取消同意并删除网关令牌的选项。
- 网关将付款人返回到您商店的网站后,提交 WS API
RETRIEVE_ORDER
请求。- 对于成功的交易:
- 如果付款人已表示同意,则响应将包含
transaction.payerConsentForStoringCardDetails=PAYER_INITIATED_PAYMENTS
字段中表示同意的信息。 - 如果付款人已表示同意且交易成功,则响应将包含
sourceOfFunds.token
字段中的网关令牌。
- 如果付款人已表示同意,则响应将包含
- 对于成功的交易:
- 对于后续持卡人发起的付款,
- 使用包含网关令牌的
interaction.tokens
请求 WS APIINITIATE_CHECKOUT
interaction.saveCardForCredentialOnFile=PAYER_INITIATED_PAYMENTS
- 这允许付款人输入并存储新的卡详细信息。<<checkout>> 向付款人显示可用的付款选项。
- 使用包含网关令牌的
- 如果付款人选择“借记卡或信用卡”,则会列出令牌的详细信息,付款人可以选择使用令牌进行支付。
商家发起交易的 <<checkout>>
商家发起交易 (MIT) 的 <<checkout>> 允许您收集付款人的同意,以存储其付款详细信息用于后续商家发起的交易。
interaction.operation=AUTHORIZE
。对 interaction.operation=PURCHASE 的其他支持即将推出。先决条件
- 确保 MSO 已为网关令牌化配置您的商家配置文件。
- 商家可以创建付款人账户并根据这些账户保存令牌信息。
- 要使用存档凭据功能,必须使用 WS API v74 或更高版本。
请求 MIT 的 <<checkout>>
按照以下步骤请求 MIT 的 <<checkout>>:
- 使用
agreement.type
和agreement.id
请求 WS APIINITIATE_CHECKOUT
Hosted Checkout 为付款人提供借记卡或信用卡付款选项。
您必须遵守组织和监管要求(例如,GDPR)。 您必须向付款人提供取消同意并删除网关令牌的选项。 - 付款人只有在同意(即选中复选框)的情况下才能继续操作。 在选中该框之前,支付按钮将被禁用。
如果付款人同意,则 Hosted Checkout 将提交具有以下值的交易请求:
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED
transaction.payerConsentForStoringCardDetails=MERCHANT_INITIATED_PAYMENTS
您必须确保付款人遵守组织和监管要求(例如,GDPR)。 您必须向付款人提供取消同意并删除网关令牌的选项。 - 网关将付款人返回到您商店的网站后,为成功的交易提交 WS API
RETRIEVE_ORDER
请求:- 如果付款人已同意,响应中将包含信息
transaction.payerConsentForStoringCardDetails=MERCHANT_INITIATED_PAYMENTS.
商家有责任确保订单或交易中不包含不需要协议的商品。 - 如果付款人未表示同意,则付款人无法继续(购物车放弃)。
- 如果付款人已同意,响应中将包含信息
常见问题
如何向网关指示付款详细信息已存储、未存储或打算存储?
为了遵守处理持卡人发起和商家发起交易的卡组织标准,您必须使用 sourceOfFunds.provided.card.storedOnFile
字段向网关指示是否已存储、未存储还是打算存储付款详细信息。
对于初始交易,即持卡人发起交易:
- 如果是一次性付款,即您不打算存储付款详细信息,则可以忽略
sourceOfFunds.provided.card.storedOnFile
字段。 - 如果是您打算存储付款详细信息以备将来使用的付款,请设置
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
。 这向网关指示付款人已同意您存储其付款详细信息。 您必须设置此值:
- 不论您在哪里存储付款详细信息 — 您自己的应用程序(需要您遵守 PCI 规范)、网关令牌化或卡组织令牌。
- 不论您是在将交易提交到网关之前还是之后存储付款详细信息。
对于后续付款,不论是使用存储的付款人付款详细信息进行的持卡人发起交易,还是使用存储的付款详细信息进行的商家发起交易,请设置 sourceOfFunds.provided.card.storedOnFile
=STORED
使用网关令牌化,网关将代表您设置默认值。
- 如果您未启用令牌化,网关会设置
sourceOfFunds.provided.card.storedOnFile
=NOT_STORED
- 当您将卡详细信息令牌化时,网关会将
sourceOfFunds.provided.card.storedOnFile
设置为等于您在交易请求中提供的值。 您可以在客户发起的交易中提供TO_BE_STORED
或NOT_STORED
。 - 当您使用网关令牌执行后续交易时,网关会设置
sourceOfFunds.provided.card.storedOnFile
=STORED
如果我没有协议 ID 怎么办?
如果您没有与付款人的协议的唯一标识符,您可以:
- 生成协议 ID 以与网关进行交互。 然后,您必须存储此 ID,并在系列中的所有付款(包括持卡人发起交易)中将其提交到网关。
- 使用现有标识符(您已经存储在系统中),例如,系列中第一个付款的订单 ID。
建立付款协议时,我是否需要提交付款?
如果在与付款人建立付款协议时,您不打算对付款人扣款,例如,如果是杂志订阅,计划在 30 天后首次付款,则必须提交包含协议详细信息的 Verify 请求 :
agreement.id
agreement.type
Verify 交易成为系列中的第一个持卡人发起交易。 对于任何后续付款,请使用 agreement.id
关联系列中的付款。
如果付款人已在 MPGS 中使用 3DS 支付验证进行身份验证,您可以提供原始交易中使用的 authentication.transactionId
。
对于经过外部验证的交易,请参阅使用身份验证 API 页面实施 3DS 集成,并导航到选项 > 提交预身份验证付款请求部分。
如果协议的 PAN 更改怎么办?
例如,在以下情况下,协议的付款详细信息可能会更改:
- 付款人的卡丢失,申领了一张新卡
- 付款人改换了银行,并且
- 卡内资金不足,付款人提供了其他付款详细信息
如果卡详细信息更改(重新发放过期的卡和卡组织令牌除外),您必须使用相同的协议 ID 执行持卡人发起交易,以更新付款详细信息或网关令牌,然后才能使用新卡号执行商家发起交易。 根据您的业务模型,您可以选择创建新协议。
如果使用卡组织令牌,组织可能会自动更新按照组织令牌存储的卡号。