现金less 与二维码支付
从博客解释转到产品页面。
自动售货中的动态二维码支付
只有当机器、手机和付款确认始终保持同步时，二维码支付流程才会显得优雅。如果交接混乱，顾客会怪机器，运营方会怪支付处理商，最后大家都在为原本可以避免的问题浪费时间。
这就是为什么动态二维码比一张静态二维码贴纸更重要。关键不在于二维码图案本身，而在于会话状态控制和确认可信度。
为什么动态二维码比静态二维码更重要
静态二维码可以把顾客带到一个支付页面，但这本身并不能形成可靠的自动售货工作流。动态二维码把二维码或会话绑定到一笔真实交易，包含金额和机器上下文。
这点很关键，因为机器必须知道到底是哪一笔会话被成功支付，以及现在是否真的可以安全出货。
- 支付会话绑定到具体购买
- 机器需要可信的付款确认
- 二维码图像本身不能解决工作流
机器到手机的交接最容易在哪里出问题
好的流程应该是：顾客选品，机器创建会话，显示二维码，然后支付结果以机器能够信任的方式返回。关键是状态管理，而不是屏幕上的一张图。
这也是薄弱部署为何总是以类似方式失败：有人扫码但没付钱，付了钱但回调来得太晚，或者手机已经完成付款但机器仍认为会话还开着。
- 定义超时和放弃规则
- 把付款确认而不是扫码当作真正的释放事件
- 让支持团队能清楚对账失败会话
二维码在哪些场景强，哪些场景弱
在顾客本来就习惯手机支付、机器屏幕足够可读，或运营方想增加一条数字支付路径而不想给每台机器都加大量硬件时，动态二维码会很强。
但当顾客预期是立即 tap‑and‑go、网络条件差，或机器侧 UX 过于笨拙时，二维码就未必是最优主路径。
- 更适合本就偏手机支付的顾客行为
- 不一定适合作为唯一支付路径
- 网络质量会直接影响商业结果
在扩展部署前应该验证什么
在扩大二维码部署前，应该测试屏幕可读性、扫码距离、付款确认行为、退款逻辑，以及对未完成会话的支持流程。
供应商比较也应重点看会话控制、对账能力、API 或 webhook 质量，以及机器侧 UX 的真实灵活度。
- 测试屏幕可读性和扫码距离
- 检查退款与失败交易处理
- 比较运营控制能力，而不仅是支付营销话术
实施层面的含义
最稳妥的部署会把这个主题变成真实工作流，而不是营销词条。因此兼容性、报表、支付、责任归属和 rollout 节奏需要一起讨论。
这些答案越早被写清楚，项目后续的返工和跨团队误解就越少。
- 把它当成真实工作流
- 把产品、运营和兼容性放在一起看
- 在 rollout 前定义责任人与测试
买方检查清单
用它判断这个主题是否已经准备好进入真正的部署讨论。
- 画清从选品到确认的完整流程
- 定义超时、放弃和失败状态
- 验证网络与支付处理商行为
- 先在适合手机支付的场景试点
- 当项目进入真实部署时转入演示或兼容性评审
有用的下一步
当二维码不再只是“有趣功能”，而是部署决策时，通常就该接回 cashless 产品页或专门的二维码指南。
常见问题
动态二维码和静态二维码有什么区别？
动态二维码绑定的是一笔具体交易和真实会话；静态二维码通常只把用户带到一个更通用的支付页面。
二维码流程一定比刷卡终端更好吗？
不一定。要看顾客行为、网络、机器 UX 和真实部署环境。
自动售货二维码支付最先坏在哪里？
通常坏在机器会话、手机付款和机器释放确认之间的同步上。
正确的下一步是什么？
在真实环境中试点，或带着机型、地区和支付处理商进入演示评审。