payment.succeeded
POST · evt_184 · ¥32支付方主动 POST 到这只信箱，店面不用每分钟去问。
先认出这只门口信箱，再决定收不收这封
下面就是支付成功时对方敲的那扇门。默认信封已验签入账。签名不对时拒收章盖在同一只信封上；同一 evt_184 再来，信箱盖「不重复入账」。
验签通过 · 已入账：结果章盖在这只信箱上。
原因：事件一发生，对方就敲这扇门。下一步：试「签名不对」，看拒收章盖在同一只信封上。
知识点：对方推过来，不是你反复去问
信封上的章已经演示了核心关系，这里只给可复用的命名。
- 事先登记回调 URL，事件一发生对方就 POST，不用轮询。
- 先验签再处理：签名不对就拒收，避免伪造入账。
- 按 event_id 幂等：同一封再来，结果相同，钱只入一次。
- 快速回 2xx；失败由对方有限重试，不是 silently 丢掉。
什么时候用、怎么用
结果发生在别人那边、你不想一直问「好了吗」时，用 webhook。
- 信号：支付、发货、第三方审批完成，客户端轮询又慢又费。
- 适用：对方能主动回调、你能验签并幂等处理。
- 不适用：对方不在线就漏通知、又没有重试——那时更像该进队列。
- 最短路径：登记 URL → 收 POST → 验签 → 按 event_id 处理 → 回 2xx。
正反例：同一笔支付通知，只换怎么收
目标都是把 ¥32 记进订单，只改验签和幂等。
信封对得上才入账；同一 evt_184 再来，信箱盖「不重复入账」。
伪造通知也能入账，重推再入一次。失败必须写在信封上。
快速自测
支付平台把同一笔成功通知连推了两次。怎样才不会入账两次？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。