团购核销怎么接事件推送, 飞书企微和自建Webhook怎么配, 无限聚核

搜「团购核销回调」「核销事件推送」，前排常见的是抖音／微信「平台官方回调」文档、微信卡券事件教程，或只讲「授权成功 Webhook」的旧文。开发者真正要的往往是：核销成功／拒绝、撤销成功／拒绝之后，结果怎么推到自己的业务系统或飞书／企微群；怎么验签、怎么按 eventId 去重；推送丢了会不会改核销结果。

一句话回答： 团购核销事件推送，切口是「核销／撤销终态怎么通知到你的业务或群」，不是平台→服务商的 SPI／卡券回调，也不是只配授权成功。飞书自定义机器人、企业微信群机器人、自建 HTTP Webhook 可订阅同一套可选事件；接收端要验签（自建 HTTP）、按 eventId 去重，并始终能用查询／对账核对最终状态——推送失败不影响核销业务结果，群消息不能当唯一入账依据。以下按无限聚核公开产品与 API 口径整理，查阅日期 2026-10-29，以账号后台与当期文档为准。

• 先划清切口： 本文写「聚合核销结果推到你自己的业务／群」；不是抖音／微信平台官方回调长文；
• 事件钉终态： 授权成功、核销成功／拒绝／未知、撤销成功／拒绝——按需勾选，勿只抄授权事件；
• 三通道同一套： 飞书／企微／自建 HTTP 选同一批事件，配置入口以账号后台为准；
• 验签与幂等： 自建 HTTP 做 HMAC 与时间窗；所有通道按 eventId（或等价键）去重；
• 推送不是账本： 不能把推送当唯一事实来源；要能查单／对账。

一、先划清：平台官方回调 ≠ 聚合核销事件推送

若你打开的是「平台官方回调 URL／SPI」配置页，和本文不是同一条链路。门店怎么建、怎么按 shopId 授权，见本站建店授权专文；SaaS 多商户授权与「授权成功 Webhook」细节见多商户团购专文——本文不整篇复读授权，只钉核销／撤销结果怎么推出去。

二、事件目录：勾选终态，不要只抄授权成功

业务到达约定终态后，可以把结果推到你配置的通道。公开产品侧常见可选事件包括：

字段名、后台勾选项以账号当期界面为准；开发者中心自建 Webhook 的历史公开文档仍以授权成功事件为主说明验签与 Challenge，群机器人通知里飞书／企微／自建 HTTP 可按后台选项订阅更广的终态事件。不要假设「配了授权成功，核销也会自动推」。

三、三通道怎么配：飞书、企微、自建 HTTP

同一套事件、三条通道： 不必为飞书写一套「核销成功」、为 HTTP 再发明一套事件名。后台按通道勾选需要的终态即可。推送是 best-effort：短超时、不保证无限重试；推送失败不会回滚已经成功的核销／撤销业务结果。

安全底线：

• 不要把完整 Webhook URL（含 query 密钥）、机器人 secret、API Key 贴进文档、群聊或截图外传；
• 轮换密钥后，接收端要同步，否则验签会整批失败；
• 群里的文本消息方便人看，不能当财务入账的唯一依据。

四、自建 HTTP：验签、时间窗、eventId 去重

自建 HTTP 面向开发者对账与状态机同步。公开文档对授权成功类事件写得很直接，接收端建议固定这几步（核销／撤销类事件若后台已开通，信封与验签习惯保持一致，字段以当期文档为准）：

1. 保留原始 Body，用配置的密钥做 HMAC（常见为 HMAC-SHA256，签名串含时间戳与原文，具体以文档为准）；
2. 校验时间窗，拒绝过期或时钟严重偏移的请求；
3. 核对事件 ID：Header 与正文中的 eventId 一致；用唯一索引原子写入，重复投递直接忽略；
4. Challenge 握手：保存 URL 时可能收到握手事件，在时限内回显 challenge；
5. 业务处理要快：验签通过后先落库事件与状态变更，发短信、刷看板放到队列，别拖垮短超时。

伪代码只示意顺序，不是可复制生产密钥的完整实现：

// 示意：先验签与时间窗，再按 eventId 去重；细节以当期公开文档为准
func handleEvent(w http.ResponseWriter, r *http.Request) {
    raw, _ := io.ReadAll(io.LimitReader(r.Body, 64<<10))
    if !verifyHMAC(r.Header, raw) || !withinTimeWindow(r.Header) {
        http.Error(w, "unauthorized", http.StatusUnauthorized)
        return
    }
    var env struct {
        EventID string `json:"eventId"`
        Event   string `json:"event"`
    }
    _ = json.Unmarshal(raw, &env)
    if env.Event == "webhook.endpoint.verification" {
        // 回显 challenge；3 秒内完成
        return
    }
    // 同一事务：插入 eventId（唯一）+ 更新业务状态；冲突则忽略
    _ = upsertIdempotent(env.EventID, env.Event, raw)
    w.WriteHeader(http.StatusOK)
}

飞书／企微自定义机器人通常是 URL 投递文本，没有与自建 HTTP 同一套 Challenge／HMAC 门禁；更要靠「查单＋对账」兜底，而不是把群消息当成已入账凭证。

五、推送不是唯一事实来源：对账与查单

落地建议：

1. 入账以业务库＋查询接口为准；推送只触发「去查一眼／刷新看板」；
2. 核销未知、超时、连点先查原单，再决定入账或告警；幂等与 10500 核对见本站幂等专文；
3. 撤销必须带齐核销返回的凭证与时限规则，推送成功不等于财务已冲正；
4. 推送通道挂了，核销本身仍应以接口同步返回为准；修好通道后靠对账补齐通知，不要重放臆造事件。

六、落地清单

联调建议：测试门店各打一笔核销成功、一笔明确拒绝、一次超时／未知、一次撤销；同时观察飞书／企微是否各收到对应文本，自建 HTTP 是否验签通过且重复投递被去重。

常见问题

团购核销回调和抖音／微信官方回调文档是一回事吗？

不是。官方回调／SPI 是平台把事件推给服务商应用；本文说的团购核销回调／事件推送，是聚合核销／撤销终态推到你自己的业务 HTTP 或飞书／企微群。配置入口、验签方式和事件名都不一样。

核销事件推送要不要单独接美团、抖音两套？

走聚合时，业务侧通常按「门店 × 平台」区分字段，但推送通道可以共用：同一飞书／企微／HTTP 订阅核销成功等事件，消息里带平台与门店标识即可。门店授权仍须美团／抖音分别完成，见建店授权专文。

只配了授权成功 Webhook，核销成功会推吗？

不会自动推。授权成功与核销／撤销是不同事件；要在后台为对应通道勾选核销成功、拒绝、未知以及撤销类事件。以账号后台当期选项为准。

飞书／企微群消息能不能直接当入账凭证？

不能。群消息方便店长／客服看见结果，入账与冲正必须以业务库记录和查询／对账为准。推送可能延迟、丢失或重复。

自建 Webhook 投递失败，核销会失败吗？

不会。推送是 best-effort，与核销业务结果隔离：投递失败不回滚已成功的核销或撤销。修好接收端后，用查询与对账补齐状态，不要靠猜事件重放。

eventId 去重和业务幂等是一回事吗？

相关但不是一层。eventId 去重防止同一推送事件被处理两次；业务幂等防止同一券码被重复核销入账。两边都要做：推送层去重＋核销层按券／单号去重。

文中产品与事件口径摘自无限聚核公开说明与开发者文档，平台官方回调规则摘自各平台公开文档标题与职责划分，查阅日期 2026-10-29，均以账号后台与当期文档为准。