本质：它不是什么黑科技，就是「预付卡核销 + 一套小电商」

大闸蟹、月饼、水果、牛羊肉这类强时令礼品，商家先卖实体提货卡（蟹卡 / 礼券），钱提前收了；持卡人扫码进公众号，用卡号 + 卡密把卡「核销」成一个收货订单，商家再按预约档期冷链发货。微信公众号在这里只承担入口和通知两个角色，真正的系统就是卡券管理 + 订单履约。

上线前的硬性前提

• 认证的服务号（订阅号权限不够，认证费 300 元 / 年），拿到 AppID/AppSecret；

• 已 ICP 备案的域名 + HTTPS 证书，微信网页授权和 JS-SDK 强制要求；

• 在公众号后台配好网页授权域名、JS 安全域名、业务域名；

• 新做的系统很多直接上小程序（授权、地址、支付体验都更顺），公众号 H5 是老方案但存量巨大。

用户侧七步（图里有完整泳道）

扫码 → 关注公众号并打开 H5 → 网页授权静默登录（不用注册）→ 输卡号 + 刮刮卡密码 → 选商品、填地址、短信验证、约发货档期 → 提交兑换 → 后台打单发货、公众号推送通知、查物流签收。

这里的关键是微信网页授权 OAuth2.0：H5 跳转微信授权页，用 snsapi_base 静默模式换 code，再用 code 换 openid，用户全程无感，系统借此识别是谁在提货。卡面二维码是「一卡一码」，里面带的是签名后的卡号 token，不是裸卡号，防止别人顺着编号遍历。

后端真正的核心：卡的安全和防超提

这是整套系统和普通商城唯一不一样、也最容易出事的地方：

1. 制卡：后台批量生成卡号（品类 + 年份 + 流水）和随机密码，密码加盐哈希存库，明文只在导出给印厂那一次出现；卡面密码区刮刮层印刷。很多卡还设「未激活」状态，渠道卖出后才激活 —— 防的就是印厂、仓库、渠道环节内鬼盗提。

2. 兑换的原子性：提交时不是先查再改，而是一条条件更新兜底，类似 UPDATE 卡表 SET 状态='已提货' WHERE 卡号=? AND 状态='有效'，数据库行锁保证并发下只有一个请求成功（影响行数为 1 才建订单），接口再叠一层幂等和按钮防重复点。开湖当天几万人同时约档期，没这层就会一张卡被提两次。

3. 防爆破：卡号密码双因子，密码连错几次锁卡 / 要求图形或短信验证；同 openid、手机号、IP 限频。

4. 档期库存：每天可发货量是有限的（冷链产能），约满即止，库存放 Redis 预扣、数据库最终一致。

5. 卡状态机：未激活 → 有效 → 已提货，旁路还有冻结、作废、过期（图三画了）。

和微信及外部的对接

• access_token 中控：调所有公众号接口的全局票据，有效期约 2 小时。多台服务器必须共用一个中控服务（存 Redis）统一刷新，各服务自取，否则互相刷新、互相踢失效，这是新手最常踩的坑；JS-SDK 的 jsapi_ticket 同理。

• 消息通知：老的「模板消息」已经下线，现在走订阅通知—— 需要用户在提货页面里主动点订阅，一次订阅对应一条下发，所以流程里要引导用户勾选「提货成功、发货提醒」。

• 微信支付：提货本身不再付钱（预付模式），补差价、多选一升级、偏远地区加运费时才用 JSAPI 支付。

• 快递侧：对接顺丰丰桥、快递 100、菜鸟的电子面单接口批量打单，发货后单号回写订单，再定时拉物流轨迹显示在提货页。

• 短信：腾讯云 / 阿里云，用于验证码和提货、发货短信兜底。

自研还是买 SaaS

中小商家基本不用自己开发：有赞、微盟以及一堆专做蟹卡礼券的提货 SaaS，在公众号后台走微信开放平台「第三方平台」授权（管理员扫码授权，不是把 AppSecret 给对方），卡券、打单、快递、订阅通知全是现成的，按年付费。只有提货量大、有多仓 / 多级分销 / 复杂兑换规则的头部商家才自研，技术栈 Spring Boot、ThinkPHP、Node 都行，底层就是图二那五层。

另外提醒两个合规点

收货地址、手机号属于个人信息，页面要最小化收集、后台脱敏展示、控制客服查看权限；卡面和兑换页要标明兑换有效期和售后规则，过期卡的处理方式提前写清楚，这类预付卡纠纷基本都出在这两处。

如果你是要自己开发，我可以接着给你：卡表 / 订单表的字段设计、兑换接口的伪代码，或者公众号网页授权的完整调试步骤，说一声就行。