团购核销怎么对账？美团、抖音核销记录与自有系统的每日核对方法

月底财务问：美团后台显示这个月核销了412张券，系统里发出去的权益只有405份，差的7张去哪了？店长回忆，有一天网络卡了，顾客连点了两次确认；也有店员在商家后台手工核过几张。没有对账，这些问题只能靠回忆。做核销系统的开发者，迟早要把“每日对账”做成一个定时任务。

一句话回答： 每天把三份数据按券逐张比对：平台的核销和撤销记录、自己系统的核销订单、店内权益的发放记录。美团可以用验券记录接口，按门店和日期拉取当天的验券记录和撤销验券记录；抖音可以用核销时保存的平台订单号，通过券状态批量查询接口查每张券的状态。比对后常见五类差异：平台已核本地没有、本地待确认平台已核、本地成功平台没有、平台已撤销本地权益还在、金额或门店对不上。对账任务只出差异单，不自动补发权益、不自动撤销，由店员确认后处理。通过无限聚核这类第三方接口核销的，再用服务商订单号 wxdgOrderNo、控制台核销记录和剩余次数核一遍。

一、对账要比对哪几份数据

对账的方向要两头都查：拿平台记录去找本地，能发现“平台核了、本地不知道”；拿本地记录去找平台，能发现“本地以为成功、平台其实没核”。

二、核销时就把对账字段存好

对账做不好，多半是核销时存得不够。建议每张券一条记录，而不是每次请求一条；一次核销多张券时，按响应里的每一项分别入库。

// 每张券一条核销记录；唯一索引 (platform, shop_id, coupon_key)
type RedemptionRecord struct {
	Platform          int       // 1美团 2抖音
	ShopID            int64     // 核销门店（无限聚核具体门店 shopId）
	CouponKey         string    // 美团存券码；抖音存券ID certificate_id（64位整数，按字符串存）
	PlatformOrderID   string    // 平台订单ID，核销成功后以 data[i].orderId 为准，抖音按它查券状态
	DealID            int64     // data[i].dealId，套餐ID
	PayAmountFen      int64     // data[i].payAmount，售卖价，单位分
	ActualPayFen      int64     // data[i].actualPayAmount，实付，单位分
	Status            string    // pending / succeeded / unknown / revoked
	ConsumedAt        time.Time // 核销时间
	ConsumeCredential string    // consumeCredential[i]，撤销时用
	WxdgOrderNo       string    // 服务商订单号，排查时用
	BenefitID         int64     // 对应的店内权益
}

三点要注意：

• 请求发出前先写一条 pending。 超时或结果未知时改成 unknown，不要直接删掉。对账要处理的主要就是这些记录。抖音的订单号和券ID在验券准备的返回里就有（order_id 和 certificates[].certificate_id；通过无限聚核时在预核销返回的 ticketData 里），写 pending 时一并存下，结果未知时也能按订单号去查；
• 金额统一按分存。 以无限聚核接口为例，payAmount（售卖价）和 actualPayAmount（实付）的单位是分，dealPrice 的单位是元，混着存，对账时金额必然对不上；
• 按平台核销时间归日。 跨零点的核销，以平台记录的核销时间决定算哪一天，本地查询也按同一口径，避免一张券被算到两天或者漏掉。

三、每日对账：五步流程

1. 次日凌晨启动。 两个平台的撤销时限都不长：按美团开放平台Go SDK中撤销验券接口的说明，只能撤销核销未超过10分钟的券；抖音开放平台文档写明验券超过一个小时不可再撤销。凌晨对前一天，记录基本已经稳定；
2. 拉美团记录。 对每家门店、每个用到的业务类型，分别查验券记录和撤销验券记录，分页拉全；
3. 查抖音记录。 取本地前一天所有抖音记录，加上所有 pending、unknown 状态的记录，按平台订单号查券状态；
4. 按唯一键合并比对。 唯一键是“平台 + 门店 + 券码或券ID”，分出五类差异；
5. 生成差异单。 每条差异写明类型、涉及的券、建议处理方式，由店员或财务确认处理，处理人和处理结果都要留记录。

// 按唯一键比对平台记录和本地记录，只产出差异单，不自动补发权益、不自动撤销
func Reconcile(platform []PlatformRecord, local []RedemptionRecord) []Diff {
	byKey := make(map[string]RedemptionRecord, len(local))
	for _, r := range local {
		byKey[keyOf(r.Platform, r.ShopID, r.CouponKey)] = r
	}
	var diffs []Diff
	for _, p := range platform {
		k := keyOf(p.Platform, p.ShopID, p.CouponKey)
		r, ok := byKey[k]
		delete(byKey, k)
		switch {
		case !ok && !p.Revoked:
			diffs = append(diffs, Diff{Kind: "平台已核本地没有", Platform: &p})
		case !ok:
			continue // 平台上核了又撤了，本地从未记录，只留日志
		case p.Revoked && r.Status != "revoked":
			diffs = append(diffs, Diff{Kind: "平台已撤销本地未回收", Platform: &p, Local: &r})
		case !p.Revoked && r.Status != "succeeded":
			diffs = append(diffs, Diff{Kind: "本地待确认平台已核", Platform: &p, Local: &r})
		}
	}
	for _, r := range byKey { // 剩下的：本地有、平台没有
		if r.Status == "succeeded" {
			diffs = append(diffs, Diff{Kind: "本地成功平台没有", Local: &r})
		}
	}
	return diffs
}

金额和门店的比对放在合并之后单独做，规则见下一节。

四、五类差异怎么处理

“本地待确认，平台显示未核销”的记录，说明这次核销确实没成功，可以改为失败，顾客下次可以重新验券核销。

金额差异里最隐蔽的是一单多张券。按美团开放平台Go SDK中验券接口的字段说明，一笔订单包含两个券码时，核销这两张券返回的支付明细 paymentDetail 是一致的，都是整笔订单的支付明细；需要每张券的分摊金额，要用订单券码分摊金额查询一类的接口单独查。按券把支付明细相加，金额会翻倍。

五、美团侧：按日期拉验券记录

美团的验券记录接口（/ddzh/tuangou/receipt/querylistbydate）按门店查询，参数是：

• date：日期；
• type：0 为验券记录，1 为撤销验券记录，两种都要拉；
• bizType：业务类型，0 普通团购、205 次卡、203 拼团、206 预订，门店卖了哪几类就分别查哪几类；
• offset、limit：从0开始分页，limit 最大300。返回条数少于 limit 才算拉完。

某一页请求失败时，整天重拉，不要跳过这一页继续比对，否则会凭空多出一批“本地成功平台没有”。

单张券的复核用查询已验券信息接口（/ddzh/tuangou/receipt/getconsumed），传券码查。

六、抖音侧：按平台订单号查券状态

抖音这边用券状态批量查询接口（/goodlife/v1/fulfilment/certificate/query/），encrypted_code 和 order_id 二选一。encrypted_code 必须取自验券准备接口的实时返回值，对账时通常已经失效，所以用核销成功时保存的平台订单号 order_id 查，看订单下每张券的状态。

这个方法有个盲区：店员在抖音来客后台手工核的券，本地没有订单号，按订单号查不到。这类记录可以从抖音来客后台导出核销明细来比对，或者用订单查询接口（/goodlife/v1/trade/order/query/）辅助。用订单查询接口要注意三点，都写在接口文档的说明里：

• 查询范围是来客商户根账户，不保证只返回某一家门店的订单；
• 订单状态1表示已完成，包含完成履约或全部退款，不能单独证明核销成功，要结合券明细的状态；
• 返回的 poi_id 是下单关联门店，可能取最近门店或随机门店，不是核销门店。

这个接口还需要应用开通订单查询能力并获得商家授权。

七、以无限聚核为例

通过无限聚核V2聚合接口核销的，对账时多了几样可用的东西。按当前公开API文档：

• 两个订单号不能混用。 核销响应顶层的 wxdgOrderNo 是无限聚核系统账单订单号，用于问题定位；data[].orderId 是平台订单ID，抖音按它查券状态；
• 撤销凭证按下标保存。 consumeCredential[i] 与 data[i] 一一对应，本地一张券一条记录，正好对上；
• 重复请求能找回首次结果。 相同业务请求命中已成功订单时，返回 success=false、code=10500（ALREADY_CONSUMED），message 给出核销时间和门店，wxdgOrderNo 与首次相同。文档同时说明，这个提示不能替代业务系统按券码和自身业务订单建立的独立去重；
• 平台原生查询也能用。 美团验券记录、查询已验券信息，抖音券状态批量查询、订单查询，都可以通过无限聚核的原生接口调用，统一用 Authorization: Bearer <token> 和 X-Store-Id 指定门店；
• 控制台核对次数。 控制台钱包页按门店显示剩余次数，并列出核销记录（接口名称、核销码、渠道、核销状态、核销门店、最近撤销、时间）；剩余次数也可以用 quota/query 接口查询。

按统一的重试规则，只有 errorCode 为 CONSUME_IN_PROGRESS、RESULT_UNKNOWN、SERVICE_UNAVAILABLE、PROVIDER_UNAVAILABLE，或请求超时没拿到响应时，才用首次请求的原样参数有间隔、有上限地重试，不换参数、不重新预核销，也不要让顾客重新输码；PLATFORM_REJECTED 和 ALREADY_CONSUMED（10500）要停止重试。重试到上限仍没有结果的，本地保持 unknown，交给次日对账。抖音次卡结果未知时不自动重试，先查券状态或对账。

剩余次数的变化和核销记录对不上时，把相关的 wxdgOrderNo 发给无限聚核排查。

八、三种接入方式，对账数据从哪来

九、上线前验收清单

用测试券把下面每一条走一遍：

• 正常核销一张券：次日对账无差异；
• 模拟核销超时：本地记为待确认，次日对账按平台记录改为成功或失败；
• 在商家后台手工核一张：对账报“平台已核本地没有”，不自动补发权益；
• 撤销一张：平台撤销记录能拉到，本地权益已回收；
• 一单两张券：本地两条记录，金额不重复相加；
• 一家门店一天超过300条记录：分页拉全，某页失败时整天重拉；
• 对账任务失败：有告警，能补跑指定日期。

十、常见问题

美团团购核销记录怎么通过接口查询？

用美团的验券记录接口 querylistbydate，按门店传日期 date、类型 type（0 验券记录，1 撤销验券记录）、业务类型 bizType 和分页参数 offset、limit，limit 最大300。单张券的复核用查询已验券信息接口，传券码查。

抖音团购券核销后怎么查券的状态？

用券状态批量查询接口，encrypted_code 和 order_id 二选一。encrypted_code 必须来自验券准备的实时返回，对账时一般用核销成功时保存的平台订单号 order_id 查。

平台后台显示已核销，自己系统里没有记录，怎么办？

先查本地有没有对应的待确认记录。有，就以平台记录为准改为成功，再检查权益有没有发；没有，多半是店员在商家后台或其他收银系统手工核销的，标记为外部核销，不要补发线上权益。

核销请求超时了，要不要让顾客重新核销？

不要。请求可能已经到达平台。按统一的重试规则，用首次请求的原样参数有间隔、有上限地重试，不重新预核销；到上限仍没有结果的，本地记为待确认，次日对账按平台记录处理。抖音次卡结果未知时不自动重试，先查券状态或对账。

对账时金额为什么对不上？

常见原因有三个：分和元混用；把实付金额和售卖价混着比；一单多张券时把整单支付明细按券重复相加。按美团开放平台Go SDK的字段说明，同一订单多张券核销返回的支付明细是一致的，都是整单的。

抖音订单查询接口能直接用来对账吗？

只适合辅助。按接口文档的说明，查询范围是来客商户根账户，不保证单门店隔离；订单状态1包含全部退款，不能单独证明核销成功；返回的 poi_id 是下单关联门店，不是核销门店。逐张对账以券状态为准。

通过无限聚核核销的，怎么和它的核销记录、剩余次数对账？

核销成功时保存顶层 wxdgOrderNo、data[i] 和对应的 consumeCredential[i]。对账时用平台订单号 data[].orderId 查平台券状态，用 wxdgOrderNo 和控制台钱包页的核销记录核对；剩余次数在控制台查看，或调用 quota/query 接口。对不上时把 wxdgOrderNo 发给无限聚核排查。

核销、撤销和查询接口的字段以无限聚核当前公开API文档为准。