支付回调应怎样验证来源与内容完整性？

追问所选渠道要求哪些原始数据、签名字段、密钥或证书？框架解析和重新编码请求体是否会影响验签，怎样构造有效与无效测试？

验签通过后，还应核对哪些交易属性？

追问商户身份、环境、本地关联、金额、币种与渠道状态如何检查？通知中缺少必要属性时，怎样查询权威交易记录或进入待核查流程？

追问事件标识、唯一约束和处理状态怎样配合？保存事件成功但处理未完成时，重复请求如何触发恢复而不是永远跳过？

追问事件去重与业务操作去重为什么不是同一个问题？支付确认、库存转换、发货任务怎样分别拥有可验证的防重依据？

追问验签、持久接收、业务处理与渠道确认如何安排？如果先返回成功后进程崩溃，怎样保证事件仍可恢复；存储失败时应该怎样回应？

追问合法状态变化、事件信息与主动查询如何防止回退？为什么只按到达顺序覆盖状态，或者只看本地接收时间，都可能得出错误结果？

追问本地交易记录、订单变化与待执行任务怎样持久保存？数据库提交后队列发送失败时，如何补发，并防止后续重复履约？

追问本地状态竞争与渠道关单结果如何共同决定处理？已经收款的事实为什么不能被本地关闭覆盖，迟到收款如何进入明确的履约或退款流程？

追问每笔收款事实怎样完整保留？订单只履约一次时，额外收款如何关联核查与退款，为什么不能把第二笔通知简单当作无关重复忽略？

追问待确认支付的定期查询、渠道事件重放与后续对账如何分工？怎样复用正常的状态处理逻辑，而不是直接写数据库绕过约束？

回调核对资料： Stripe：Webhooks。通知格式、签名校验、重试与顺序约定按所选渠道确认；本地可靠接收与业务防重属于项目自身需要验证的设计。