本页是字典和批量工具：哪些事件作为 Portal 可跟踪的
事件存在、每种事件携带哪个标识以便你匹配到自己的记录、日志
能追溯多远，以及如何一次重放整个时间窗口内的失败。
Portal 跟踪哪些事件类型？
八种。 这是 Event Type 筛选项提供的确切集合，也是你 留空该筛选项时搜索的集合：
两点能省去无谓的搜索：
- 拒付事件只有一种。 每次拒付创建和案件上的每次状态变化
都以
CHARGEBACK_NOTIFICATION到达。没有单独的预警事件，也没有 单独的拒付退款事件可以订阅。 eventType列中的值就是上面的值，所以你在 Portal 中读到的 就是你在自己代码中匹配的。友好标签仅用于显示。
我如何把一条回调通知匹配回自己的订单？
每条记录携带一个 Order ID，它是哪个标识取决于事件。这 是对照表：
拒付这一行是让人意外的，所以说得直白一点：按你的原支付订单号搜索日志
找不到拒付通知。 那里的 Order ID
列是案件自身的标识，不是你的订单。打开记录，从请求体中读取
originalOrderId。反过来同样要注意——不要把
拒付日志的 Order ID 用作你自己系统中的键。
对于订阅，注意升级或降级会产生一个新的订阅 ID，所以
SUBSCRIPTION_CHANGE_NOTIFICATION 不会匹配你变更前持有的订阅 ID。
如果你以它为键，请从载荷中读取原 ID。
其中哪些是我能订阅的，URL 从哪里来？
只有两个回调 URL 是你在 Portal 中设置的；其余的随创建该对象的 API 调用 一起传递。回调通知日志页面上没有任何东西能改变 URL——该页面按设计 是只读的。
Portal 侧 URL 的配置在
Portal 自助安全配置中说明。如果
某个事件完全没有产生日志记录，通常的原因是没有解析到 URL——参见
回调通知事件日志与手动重发。
回调通知日志能追溯多远？
90 天。 页面在横幅中如此说明，日期选择器不允许选择 90 天前更早的日期，Retry by Date 也受同一窗口限制。对于更早的内容， 请通过其查询 API 查询对象本身，而不是寻找通知。 两个相关的边界：- 日志从该功能上线的时间点开始。更早的通知不会回填，所以 一笔很老的交易返回空结果是预期之内的，而不是诊断依据。
- 列表默认按 Submission Time 排序，最新的在前。
我能一次重放整个时间窗口内的失败吗？
可以——Retry by Date，它正是为你的端点在某段时间内宕机、 而你希望重新投递该窗口内的失败而无需逐条点击的情形而存在的。
批量重发（多选、Retry by Date）只作用于失败的记录——成功的记录不会被批量包含，只能在日志里单条重发，所以你
不会意外地批量重新投递你的端点已经接受的内容；进行中的记录同样不会包含在内。
一个批次最多能重发多少条？
每次请求最多 50 条记录。 这同样适用于 Retry by Date 和多选重发， 并且在两端都强制执行，而不只是 UI 提示。 实际意味着什么：
批次不会被静默截断为前 50 条——超限的范围会被直接
拒绝。这是有意为之：被截断的批次会让你以为一个窗口已经
重放，而其实大部分没有。对于大量积压，请分片处理——先按事件
类型分，因为那通常正是沿着你事故实际发生的线路
切分窗口。
批量重发后我会得到什么？
按记录的结果，以计数而非单一的通过/失败汇总：
“成功”意味着你的端点在本次尝试中接受了投递——批次报告的是
真实的投递结果，而不仅仅是请求已排队。所以一个返回全部
失败的批次是在告诉你，你的端点仍然不接受载荷；在再次重放之前
先修复它。
在预估和发送之间状态发生变化的记录——例如在此期间通过
自动重试成功了的记录——会计入失败计数而不是被重发，
因为它们已不再符合条件。
手动或批量重发会消耗我的自动重试次数吗？
不会。 手动或批量重发都不会消耗自动重试次数，也不会让失败的记录重新回到自动重试队列。 手动或批量重发前，该记录会先被移出自动重试队列。如果你的端点不接受这次重发，记录保持失败状态（NOTIFY_FAILED），Next Retry 显示 —，不会再接回自动重试；需要再次发送时，由你再手动发起。
实际规则：先验证你的端点，再重放。 重放失败的记录会一直保持失败状态，需要你再次手动重放。
Portal 把什么视为”Failed”记录？
Failed 既包括已最终失败的记录，也包括本次失败但
仍在自动重试队列中的记录。两者通过 Next Retry 列
而不是状态来区分：
这对 Retry by Date 很重要：预估统计的是两种失败记录，所以
你重放的窗口可能包含本来会自行恢复的记录。
为什么成功的记录不显示我端点的响应？
因为成功的记录没有单独存储你的服务器返回的响应内容。只有当你的端点返回 HTTP 2xx 并且响应体为{"message":"success"} 时，投递才算成功，依据
回调通知概览。
失败信息只记录在失败的记录上，那里会显示你的端点返回的失败摘要——或传输错误。所以在你排查时，失败的记录才是有信息量的。
重发会在日志中创建第二行吗？
不会。通常每个业务对象的每个事件只有一条记录——同一支付订单的支付 通知在其整个生命中是一行。重发会就地更新该行的状态、响应和 尝试次数；不会新增一行。详情视图中的 Notify Count 是你的 尝试历史。拒付通知例外：它的 Order ID 是案件标识加一个随机数，每次状态变化都会产生新的一行。 这也是为什么你不能用行数来衡量投递量，以及为什么重发过的记录 在后来的尝试覆盖之后会丢失之前的失败摘要。如果你期望的记录是完全缺失而不是失败，请从 回调通知事件日志与手动重发开始——缺失的记录 几乎总是意味着没有解析到回调 URL，这是重发无法修复的。