news 2026/10/22 19:11:51

刚注册完不会核销?卡点在建店和授权:商户 → 门店 shopId → 美团/抖音授权

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
刚注册完不会核销?卡点在建店和授权:商户 → 门店 shopId → 美团/抖音授权

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

账号注册好了,开发者中心也能看到 API Key,一点核销却报「门店不存在」「未授权」——现场最常见的不是接口写错,而是还没建具体门店,或者建了商户却拿商户 ID 去授权。

新客里「注册了但行业未知、门店为空」的比例很高;美团侧核销量通常也远大于抖音。所以这篇只盯一条新手路径:注册 → 建商户 → 建具体门店(拿到 shopId)→ 美团授权 → 抖音授权。跑通这一条,才能开始预核销和核销。洗车、健身、台球、舞室这类自助业态,以及给门店做系统的行业软件,步骤一样。

先给结论路径:

  1. 注册无限聚核账号,在开发者中心拿到 API Key(只放服务端);
  2. 控制台先新建商户(选业务类目),再在该商户下新建具体门店,记下返回的shopId;
  3. 用具体门店的shopId分别发起美团、抖音授权;商家本人在平台页确认;
  4. 回到门店列表,核对授权状态和平台显示名,确认绑的是这家店;
  5. 有券、有授权之后,再接预核销 / 核销(那是下一篇文章的事)。

关系示意:授权和核销用的是具体门店shopId,不是商户 ID。

一、注册之后立刻做的两件事

注册本身不绑定门店。账号活了,只说明你能登录控制台、能拿凭据。

步骤做什么验收标准
拿 API Key登录后打开开发者中心,复制当前账号的 API KeyKey 完整、只保存在业务服务端配置,不进小程序包、不进前端仓库
确认业态想清楚门店是服务零售还是到店餐饮建商户时类目选对;洗车、健身、台球、舞室等一般走服务零售;餐厅另走餐饮,别混用示例

API Host、请求头格式以当前公开 API 文档为准。常见写法是服务端请求头带Authorization: Bearer <key>;具体 Host 和路径前缀以文档「快速开始」为准,不要抄过期博客。

个人、工作室、公司都可以注册接入;无限聚核对接入方没有营业执照要求。能不能核销,前提是门店已经在美团 / 抖音开出来,并能完成授权——开店资质看平台规则,一般要营业执照(个体工商户即可),以平台入驻页为准。

二、先建商户,再建具体门店

无限聚核后台是两级:商户组织一组门店;门店才是授权和核销的对象。商户本身不做授权、也不接受核销请求。

控制台操作顺序:

  1. 打开门店列表,点新建商户;
  2. 填内部名称(给自己看的,比如品牌名或客户名),选择业务类目(服务零售 / 到店餐饮);
  3. 在该商户卡片下点新建门店,填具体门店名称(建议带店址或店号,方便以后对账);
  4. 创建成功后,门店会有独立的shopId——把它记进自己的业务门店映射表。

真实后台截图示意(已裁切、敏感信息遮盖):保留「新建商户」「新建门店」和逐店授权入口。

真实后台截图:新建商户先填内部名称并选业务类目。

真实后台截图:门店创建后获得独立shopId。

要把入驻放进自己的 SaaS / 行业软件后台时,可调「创建商户或门店」接口POST /api/hexiao/v2/store/create(字段以当前文档为准):

  • 不传masterShopId:只创建商户;返回的data.shopId是商户 ID,不会自动创建首家门店;
  • 再传masterShopId(上一步的商户 ID):在该商户下创建具体门店;这次返回的data.shopId才是后续授权、预核销、核销要用的门店 ID;
  • businessCategory只在创建商户时生效(service_retail/dining,省略时默认服务零售);创建门店时继承商户类目,门店请求里带这个字段会被忽略。
POST /api/hexiao/v2/store/create Authorization: Bearer <key> Content-Type: application/json { "shopName": "示例商户", "businessCategory": "service_retail" }
POST /api/hexiao/v2/store/create Authorization: Bearer <key> Content-Type: application/json { "shopName": "示例门店·人民路店", "masterShopId": 123 }

上面的数字和名称都是占位示例。连锁有几家实体店,就建几个无限聚核门店;一家店对应一条shopId映射,不要让十家店共用一个商户 ID 去核销。

本步验收:门店列表里能看到商户卡片,卡片下有具体门店,并且你已经把门店shopId(不是商户 ID)写进自己的系统。

三、分清四个 ID,别塞进同一个字段

接到「门店不存在 / 当前 shopId 对应主门店」一类报错时,先对这张表:

名称是什么能不能拿去授权 / 核销
自己系统的业务门店 ID行业软件、小程序里的门店主键否;要先映射到聚核门店
无限聚核商户 ID组织用;store/create不传masterShopId时返回的那个否;传给授权接口会报仅支持子门店
无限聚核具体门店shopId商户下新建门店后返回的 ID是;授权、预核销、核销、撤销都用它
美团 / 抖音平台门店或账号显示名授权后在列表里看到的平台侧信息用于核对绑对没有,不是聚核请求里的shopId

一句话:业务调用里的shopId= 具体门店 ID。

四、美团授权:优先把这一侧跑通

数据上美团核销量通常更大,新手建议先完成美团授权,再补抖音。

控制台路径:在门店列表找到目标具体门店 → 点美团授权入口 → 把链接交给管理该店的美团账号本人打开并确认。

自建后台时,调「获取美团/抖音授权链接」:

POST /api/hexiao/v2/get/auth/url Authorization: Bearer <key> Content-Type: application/json { "shopId": 123, "platform": 1 }
  • shopId:必须是具体门店;
  • platform:1美团,2抖音;不传时默认美团;
  • 成功时data是授权 URL(以文档响应为准)。

拿到链接 ≠ 授权完成。商家还要在美团页面点完确认;你这边还要回门店列表核对:美团授权状态为已授权,平台显示名能对上这家店。配置了授权成功 Webhook 的,也不能只信一次投递,文档口径是 best-effort、不自动重试,最终仍以查询或后台列表为准。

跟老板怎么说,少绕弯:

  • 用哪一个美团账号登(必须对目标门店有权限);
  • 授权给谁、授权后能干什么(验券、核销、撤销);
  • 多店时逐家点,避免 A 店链接落到 B 店。

本步验收:该门店美团状态已授权;用测试券(或店主确认有在售套餐的门店)可以进入后续预核销联调;报错里不再出现未授权类原因。

授权场景示意:门店、授权链接、成功状态是三步;图中界面不是真实后台。

五、抖音授权:另一条线,不能共用美团结果

同一家聚核门店,抖音要单独再走一遍:控制台点抖音授权,或get/auth/url传platform: 2。商家用来客侧有权限的账号确认。

注意:

  • 美团已授权不能代替抖音;
  • 只开了一个平台的店,可以先接这一个,另一个平台开店后再补授权;
  • 授权后同样核对抖音显示名,防止绑错店。

本步验收:门店列表里抖音状态单独为已授权(若本店暂不接抖音,可明确标记「未开抖音 / 暂缓」,不要误以为美团勾上了就两边都能核)。

六、授权完才能核销:最小联调顺序

门店和授权齐了,再动接口。最小顺序(细节以 API 文档为准):

  1. 服务端保存 API Key 与业务门店 → 聚核shopId映射;
  2. 预核销(文档称「输码验券校验」):同一shopId、platform、券码;
  3. 顾客 / 店员确认套餐后,再核销(文档称「验券」);
  4. 成功只看顶层success为布尔true,并保存首次成功结果与凭证。

预核销、核销、撤销、错误码重试不是本文重点;把建店和授权卡点清掉之后,再对照接入实战文档联调即可。

七、常见卡点 FAQ

注册完为什么还是核不了?

因为核销落在具体门店 + 对应平台已授权上。只注册、只拿了 API Key、或只建了商户没建门店,请求都会失败。按本文第二节、第四节做完再试。

商户和门店必须都建吗?可以只建一个吗?

必须先有商户,再在商户下建门店。只建商户拿不到可授权的shopId;不传masterShopId的store/create也不会自动创建首家门店。

授权接口报「当前 shopId 对应主门店,该接口仅支持子门店」是什么意思?

你传的是商户 ID。换成该商户下某家具体门店的shopId再取链接。

美团授权了,抖音还要授权吗?

要。两个平台状态分开记、分开核对;platform分别传1/2。

连锁十家店,授权一次就够了吗?

不够。几家实体店就建几个聚核门店,每店 × 每平台各走授权;不要共用一个shopId。

控制台建店和接口建店有什么差别?

结果一样:都是商户下的具体门店 +shopId。控制台适合人手少、店不多;行业软件 / SaaS 要把入驻做进自己后台时再接store/create和get/auth/url。

授权链接发给谁?开发者能代点吗?

发给管理该店的美团 / 抖音商家账号,必须本人在平台页确认,开发者代不了。多店时写清店名,降低选错店概率。

字段、类目、报错文案和文档不一致怎么办?

以无限聚核当前控制台和公开 API 文档为准;本文示例只保留主线,不保证穷尽所有字段。

八、做完这一页再往下走

勾完下面这些,再排预核销联调:

  • API Key 仅在服务端;
  • 已建商户,类目正确;
  • 每家实体店都有独立聚核门店shopId,并已写入业务映射;
  • 目标店美团已授权且显示名核对无误(若接美团);
  • 目标店抖音已授权且显示名核对无误(若接抖音);
  • 没有把商户 ID、业务门店 ID、平台门店 ID 塞进核销请求的shopId。
版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/20 14:41:01

UCOS-II多任务系统时钟配置与任务调度实战指南

简介&#xff1a;这份资源是面向嵌入式专业学生与初学者的UCOS-II课程设计资料&#xff0c;围绕多任务调度与系统时钟两大核心展开&#xff0c;帮助读者在真实工程中理解实时操作系统&#xff08;RTOS&#xff09;的任务管理机制。内容涵盖UCOS-II的移植与配置、任务创建与优先…

作者头像 李华
网站建设 2026/10/23 3:32:45

Verilog加法器设计全攻略:从RTL代码到FPGA综合优化

最近在做数字逻辑课程的实验&#xff0c;有个学弟问我加法器到底怎么用 Verilog 写才规范&#xff0c;是不是直接写assign sum a b;就够了。这问题其实很有意思。加法器是数字电路的基石&#xff0c;从最简单的半加器到 ALU 里的关键路径&#xff0c;几乎每个数字系统都离不开…

作者头像 李华
网站建设 2026/10/21 18:35:00

BlendMask实例分割:融合Top-Down与Bottom-Up的轻量高效方案

做实例分割调研的那段时间&#xff0c;我一直在 top-down 和 bottom-up 两条路线之间反复比较。Mask R-CNN 这类方法精度确实稳&#xff0c;但 RoI 相关的计算量摆在那里&#xff0c;训练和推理都不便宜&#xff1b;YOLACT 那种纯 bottom-up 的玩法速度是快&#xff0c;可一旦画…

作者头像 李华
网站建设 2026/10/18 9:27:56

存量市场服务升级:低风险高回报的商业模式

1. 为什么说"稳妥生意"比创业更值得关注最近三年&#xff0c;我身边有37位朋友尝试创业&#xff0c;最终存活下来的只有3家。这个残酷的数字让我开始思考&#xff1a;对于大多数普通人来说&#xff0c;是否存在着比创业风险更低、回报更稳定的商业机会&#xff1f;经…

作者头像 李华
网站建设 2026/10/19 4:17:40

完全重建QAM滤波器组:从子带编码到比特分配的工程实践

做数据压缩作业时&#xff0c;我把“完全重建QAM滤波器组”这组概念翻来覆去折腾了两周。刚开始顶着“滤波器组不是通信课的东西吗&#xff0c;跟压缩有什么关系”的疑问硬啃&#xff0c;等到代码跑通、频谱图一张张摆出来&#xff0c;才真正明白子带编码的底气全部系在“重建质…

作者头像 李华