Adyen争议交易报告：拒付通知与信息请求是两种不同条目

在Adyen的Dispute transaction details report（争议交易明细报告）里，Notification of Chargeback和Request for information是两个并列的状态条目，不能合并统计。按该页定义，前者是“待处理拒付的通知”，后者是“就该笔支付请求更多信息”。两者都会触发对应的webhook，但含义不同：一个是拒付流程尚未落定的通知，一个是信息补充请求。需要强调的是，这两个状态只是报告中的分类标签，不等于客户到账结果、风控判定或发卡行承诺。

两个条目的定义边界

该页对争议交易明细报告收录状态的定义很简短，能确认的只有以下两点：

• Notification of Chargeback：pending chargeback的通知。关键词是“pending”，即拒付已被通知、尚处于待处理状态。
• Request for information：针对该笔支付请求更多信息。它本身不是拒付通知，而是信息层面的请求。

这两个定义只说明条目性质，不说明提交材料的截止时间、处理时限或后续结果。该页没有给出这些内容，因此不应从条目名称反推时限，也不应把“Request for information”当作拒付已成立，或把“Notification of Chargeback”当作最终拒付。

核对动作：在报告里怎么区分

拿到争议交易明细报告后，可以按以下步骤核对：

1. 定位状态列，逐行读取状态值，不要只看交易金额或交易号判断条目类型。
2. 把状态值与上述两个定义逐字对应：出现“Notification of Chargeback”的，归为待处理拒付通知；出现“Request for information”的，归为信息请求。两者各自成类，不合并统计。
3. 对同一笔支付出现多个争议相关条目时，按状态分别记录，不假设后一条目自动覆盖前一条目——该页未说明条目之间的替代关系。
4. 与webhook对账：该页说明这两个状态都会发出webhook。可用webhook记录与报告条目按支付维度比对，确认没有把一种状态误记为另一种。
5. 不依据该页推断时限：涉及回复或提交材料的截止时间，应另找对应规则页面确认，本文不给出此类结论。

一个可复算的归类例子

假设某份争议交易明细报告中有三行记录，数值为演示用，非真实数据：

按该页定义归类：待处理拒付通知共1条，金额合计100；信息请求共2条，金额合计150。若误把三行都算作“拒付相关”，会得到3条、250的错误口径。这个例子只演示分类口径，不涉及任何时限或处理结果。

常见误读

• 把信息请求当成拒付：Request for information只是请求更多信息，定义中不含拒付成立的含义。
• 把待处理拒付通知当成最终拒付：Notification of Chargeback明确是pending状态的通知。
• 用条目名称推截止时间：该页定义不包含时限信息，任何截止时间都需以专门规则页为准。
• 把报表状态当成结果承诺：报告条目只反映该页所定义的状态，不能据此推断客户到账、风控结论或发卡行动。

在报告核对中，把这两个状态当作两个独立标签处理，是避免口径混淆的最直接做法。

原始资料

docs.adyen.com