1
我方二维码消费确认
设备通过 weburlA 请求二维码，由我方消费系统生成并返回，用户扫码后进入我方系统确认扣款。
产品定位
这不是一台孤立的咖啡机介绍，而是一个可复制的智慧食堂外部售卖设备接入样板。
| 项目 | 内容 |
|---|---|
| 硬件对象 | 妙雀 308 / 318K 咖啡机 |
| 目标场景 | 园区、企事业单位、环卫项目、员工餐厅、智慧食堂自助售卖点 |
| 使用对象 | 就餐用户、项目运营方、设备运维人员、财务对账人员、交付实施人员 |
| 核心边界 | 咖啡机展示二维码并自行出货；我方处理消费确认、扣款状态、出货结果、异常订单和对账 |
为什么现在值得做
消费入口统一
让咖啡消费进入餐卡、余额、补贴等自有消费体系，减少独立支付和独立对账。
异常处理统一
出货失败、扣款超时、订单关闭不再散落在设备侧，能进入我方订单状态和人工处理链路。
设备经验复用
把这次对接抽象成第三方售卖设备标准包，后续可扩展到售卖柜、取餐柜和自助终端。
特色功能
2
扣款状态轮询
设备通过 weburlC 查询等待、成功、过期、关闭和完成状态，扣款成功后再制作或出货。
3
出货结果回传
设备通过 weburlB 回传出货成功或失败，我方记录最终订单状态并触发后续处理。
4
设备台账与密钥管理
按 machid/appkey 建立设备台账，结合点位、别名、启用状态和签名校验定位问题。
5
交易对账采集
拉取成功和失败交易记录，与我方订单核对，沉淀差异清单、异常工单和经营报表。
6
库存与设备状态同步
查询库存、缺货、在线离线和故障状态，让运营和交付更早发现设备问题。
标准业务流程
选择咖啡
用户在咖啡机上选商品，设备生成订单。
请求二维码
设备调用 weburlA，我方校验后返回二维码数据。
确认扣款
用户扫码进入我方消费系统，按餐卡、余额或补贴扣款。
查询结果
设备调用 weburlC 轮询扣款状态。
制作出货
扣款成功后，咖啡机自行制作或出货。
回传结果
设备调用 weburlB 回传成功或失败。
异常处理
出货失败进入冲正、退款、补贴返还或人工核对。
对账运维
系统采集交易、库存、在线和故障状态。
方案优势
| 角色 | 关注点 | 买点 |
|---|---|---|
| 项目运营方 | 咖啡消费是否纳入统一经营 | 咖啡机交易进入智慧食堂订单、对账和设备管理链路。 |
| 就餐用户 | 支付是否简单 | 扫码后进入我方消费确认，体验接近食堂内统一消费。 |
| 财务/后勤 | 余额、补贴、退款是否可控 | 不走独立第三方支付，便于按我方消费系统规则处理扣款和异常。 |
| 设备运维 | 设备问题是否可定位 | 设备台账、库存、在线状态、交易失败和出货异常形成运维线索。 |
| 交付实施 | 下一台设备是否能复用 | weburlA/C/B、设备台账、签名校验、测试用例和验收清单可沉淀为标准包。 |
适用场景
这类硬件更适合“已有智慧食堂消费体系，希望扩展自助售卖能力”的项目，而不是只买一台独立收款咖啡机的项目。
适合
- 园区、企事业单位、学校、医院、环卫等统一食堂消费场景。
- 已有餐卡、余额、补贴或内部账户体系。
- 需要把设备交易、库存、故障、在线状态纳入运营看板。
不适合
- 只想让咖啡机独立微信或支付宝收款。
- 要求我方远程控制咖啡机制作动作或下发配方。
- 厂家不能提供测试设备、密钥、轮询规则和错误码。
证据与待确认项
已有证据
- 已归档妙雀 308 第三方支付二维码说明文档和对外 API 文档。
- 已归档妙雀 318K 第三方支付二维码 PDF，并完成 308 / 318K 参数差异对比。
- 当前判断：两类设备在
weburlA/C/B、参数、返回码、签名和业务流程上未发现实质差异。 - Jack 已确认 V1 按取餐柜/售卖柜同类“外部设备消费扣款闭环”处理。
待确认项
- 318K 实机固件是否完全按 PDF 中 V2.4 协议执行。
- 设备点位、设备数量、测试机、测试账号和
machid/appkey。 twocode展示能力、轮询间隔、最大等待时间和错误码表。- 出货失败后的冲正、退款、补贴返还或人工处理责任边界。
上线影响
产品
形成第三方售卖设备接入标准包，提升后续自助设备接入复用率。
交付
把接口、设备台账、测试用例、厂家确认项和验收指标提前标准化。
运营
让咖啡机消费从独立交易变成可追踪、可对账、可运维的经营数据。
下一步动作
如需对客户发布，需要补真实设备照片、现场点位图、已联调截图、客户授权口径，以及支付成功率、出货成功率、对账差异率、设备在线率等验收数据。