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

> 核销服务由无限聚核提供，美团、抖音团购核销一站式接入。

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

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

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

![示意图：左栏列出授权成功与核销／撤销成功拒绝未知等终态事件；中栏飞书机器人、企微群机器人、自建 HTTP 三通道开关；右栏 HMAC 验签、时间窗、eventId 去重、对账查单](assets/hero.jpg)

*示意图：通用产品口径（2026-10-29 查阅），不是真实后台或群机器人界面。抖音／微信「官方回调文档」解决的是平台→服务商事件，不是「聚合核销结果推到你自己的业务／群」。*

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

| 说法 | 常见出处 | 和「团购核销回调」目标词差在哪 |
|---|---|---|
| 抖音撤销核销消息／推送核销状态 | 抖音开放平台合作伙伴文档 | 平台→**服务商／应用**的官方通知，不是你自己的飞书／企微／业务 HTTP |
| 微信卡券／代金券核销事件 | 微信开放平台、支付合作文档 | 卡券 SPI／事件回调，切口是微信侧券生命周期 |
| 授权成功 Webhook | 旧接入文、部分 FAQ | 只覆盖「门店授权成功」，不覆盖核销／撤销终态 |
| 团购核销事件推送 | 本文切口 | **核销／撤销结果推到你的业务系统或群**；飞书／企微／自建 HTTP 同一套可选事件 |

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

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

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

| 事件（口语） | 典型用途 | 注意 |
|---|---|---|
| 授权成功 | 开通进度、开通看板 | 旧文多只写到这一条；不够覆盖核销现场 |
| 核销成功 | 业务入账提醒、群播报 | 仍须用查询／流水核对后再改订单状态 |
| 核销拒绝 | 失败告警、客服跟进 | 拒绝原因以接口返回与后台记录为准 |
| 核销未知 | 超时／不确定态告警 | **禁止**把未知当成功入账；先查单 |
| 撤销成功 | 冲正提醒 | 撤销规则与时限见撤销专文，本文不复读 |
| 撤销拒绝 | 冲正失败告警 | 窗口外、凭证无效等需人工核对 |

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

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

| 通道 | 适合谁 | 配置要点（公开口径） |
|---|---|---|
| 飞书自定义机器人 | 运营／店长群播报 | 在飞书建自定义机器人，把 Webhook 填进后台「群机器人通知」；按事件勾选 |
| 企业微信群机器人 | 企微运营群 | 同上，选企微提供方；URL 只放后台，勿写进公开文章 |
| 自建 HTTP Webhook | 业务系统对账、状态同步 | 提供可公网访问的 HTTPS 接收端；保存前常有 Challenge 握手；业务事件带签名 |

**同一套事件、三条通道：** 不必为飞书写一套「核销成功」、为 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. **业务处理要快**：验签通过后先落库事件与状态变更，发短信、刷看板放到队列，别拖垮短超时。

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

```go
// 示意：先验签与时间窗，再按 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 门禁；更要靠「查单＋对账」兜底，而不是把群消息当成已入账凭证。

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

| 信号 | 快慢 | 准不准 |
|---|---|---|
| 事件推送（群／HTTP） | 快 | 可能丢、可能乱序、可能重复 |
| 主动查询核销／门店／流水 | 按需 | 以服务端已保存记录为准 |
| 定时对账导出 | 慢 | 适合日终／班次核对 |

落地建议：

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

## 六、落地清单

| 项 | 通过标准 |
|---|---|
| 切口 | 文档写明「核销／撤销结果推送」，未把平台官方 SPI 或「仅授权成功」当成全文 |
| 事件 | 按需勾选核销／撤销终态；未默认假设全开 |
| 通道 | 飞书／企微／自建 HTTP 按角色选用；密钥不外传 |
| 验签 | 自建 HTTP 验签＋时间窗＋eventId 去重已测 |
| 幂等 | 重复推送不重复入账 |
| 对账 | 有查单／流水核对路径；群消息不作唯一账本 |
| 失败隔离 | 确认过：关掉推送或投递失败，核销同步结果仍正确 |

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

## 常见问题

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

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

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

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

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

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

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

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

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

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

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

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

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