Webhook
同一条支付成功通知来了两遍，为什么不能发两份课程权益？
Webhook 是事件发生后由一个系统主动向另一个系统约定地址发送通知的集成方式，常通过 HTTP POST 实现。接收方需要验证通知、识别事件并安全处理重试、重复或顺序变化。
不用一直去问有没有新消息，对方发生事情后按约定通知你。但通知可能重发，要先验明来源，再确认是不是同一件事。
像快递发来的取件通知：第二条提醒不一定代表又来一个包裹，要按同一个运单号认清。
类比到这里为止：Webhook 是程序请求，公网入口可能收到伪造内容。验签方式、重试次数与事件顺序要看提供方协议，不能凭人类短信类比直接信任。
课程支付平台通知交易变化后，系统核对事件和实际支付事实，再更新对应权益。外贸平台通知新线索时，同样不要按通知次数重复新建客户。
接收通知时真正要做的检查
- 来源与完整性
- 按提供方协议验证签名或其他凭据；某些验签要求使用原始请求体。
- 事件与对象
- 区分事件编号、业务对象编号和事件类型，按约定决定去重标识。
- 重复与顺序
- 记录已处理结果，必要时核对最新业务状态，避免旧通知覆盖新状态。
- 响应与后续
- 在协议要求内及时确认可靠接收，异步处理保留失败和重试记录。
与主动查询搭配，而非互相冒充
通知可以让系统知道值得检查哪件事，查询接口可以帮助核实当前事实。若通知丢失或处理出错，还需要按业务重要性设计补偿与核对方式。
例子只解释公共机制，不连接真实支付与 CRM，不代表本站已经具备交易和自动开课能力。
继续看项目应用与交付检查
Webhook 在项目中负责什么
- 什么时候用
- 需要及时接收外部系统的业务事件，减少频繁主动查询时。
- 它解决什么
- 把事件源与接收业务连接起来，让后续处理有明确触发信息。
- 它不负责什么
- 通知送到接口与接收方业务完成是两件事。处理耗时可按平台协议入队，但不能未可靠接收就随意确认成功。
- 放进真实项目
- CRM 收到新询盘后自动通知负责销售，并创建待跟进任务。
Webhook 让一个系统在事件发生后主动通知另一个系统
CRM 出现新线索或支付状态变化时，网站不必不断询问“有变化吗”，而是让来源系统主动把事件送过来。
- 01
只订阅真正需要响应的事件。
- 02
校验签名与事件 ID，防伪造和重复。
- 03
先接收并记录，再异步处理较慢工作。
先验证、再辨认、后处理；重复通知不等于新业务。
容易混淆的地方
Webhook 不是前端弹窗，也不天然按顺序只到一次；具体保证由服务协议决定。
支付平台把同一笔成功事件通知了两次。课程系统应该怎样处理？
你可以这样告诉 AI Agent
我在处理这件事：CRM 收到新询盘后自动通知负责销售，并创建待跟进任务。请以“Webhook”为主线，先说明它在这里负责什么、不负责什么；再列出必要输入、建议动作和可验证结果。用外贸独立站的业务语言回答，不确定的信息标为待确认。
内容依据与延伸
本站用原创中文解释把专业概念映射到外贸独立站；定义和机制继续以官方资料为准，业务例子再回到 外贸独立站询盘优化实战 验证。
本站整理说明：站内案例：新询盘自动提醒销售