ThinkPHP微信卡券功能开发教程创建与二维码领取详解

做微信卡券功能，尤其是用ThinkPHP这类框架时，最磨人的往往不是业务逻辑，而是那些藏在文档角落里的配置项和格式要求。一个参数没对齐，一个IP没加白，后面所有的接口调用都可能直接卡住。咱们今天就把几个最容易“踩坑”的关键环节捋清楚。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

微信卡券接口调用前必须确认的 3 个配置项

首先得明确，ThinkPHP本身不提供任何微信卡券能力，所有操作都依赖微信官方的card接口。而调用这些接口的前提，是完成基础鉴权和资源准备。这三项但凡漏掉一个，后续请求大概率会收到{“errcode”:40001,“errmsg”:“invalid credential”}这类令人头疼的错误。

• 账号与权限：使用的APPID和APPSECRET必须与绑定了卡券功能的公众号/小程序主体完全一致。别忘了，公众号后台的「功能插件」里，得确认已经开通了“微信卡券”功能。
• 服务器IP白名单：这是很多开发者会忽略的一步。调用获取access_token的接口https://api.weixin.qq.com/cgi-bin/token时，请求服务器的IP必须在公众号后台的「IP白名单」中登记，否则请求会被直接拒绝。
• 物料格式硬性要求：创建卡券时用到的logo_url和code_color等字段，微信有非常严格的格式规定。Logo图片必须是300×300像素的PNG格式，且大小不能超过200KB；而code_color（卡券码颜色）必须填写合法的十六进制颜色值，比如“FF6B00”，注意不能带#号。

创建卡券时最常出错的 JSON 结构问题

在ThinkPHP里用curl或者框架自带的Http::post()提交卡券数据时，失败往往不是代码逻辑问题，而是JSON结构或字段类型与微信规范不符。微信的接口对字段顺序、嵌套关系甚至空值的表示方式都有严格要求。

• 警惕二次JSON编码：一个常见的坑是，手动json_encode($data, JSON_UNESCAPED_UNICODE)后，再交给ThinkPHP的Http::post()方法，该方法可能会对数据再次进行编码，导致最终发送的是一个被转义过的JSON字符串，微信服务器自然无法正确解析。
• 空值必须显式声明：比如location_id_list（门店列表）字段，即使你不设置任何门店，也必须传递一个空数组[]，传递null或者直接省略这个字段，都会导致接口报错（errcode:40059）。advanced_info里的子字段也是如此。
• 注意单位与类型：对于优惠券（cash类型）的least_cost（最低消费）和reduce_cost（减免金额）字段，单位是“分”，且必须为整数。传递浮点数（如10.5）或带单位的字符串（如“10.5元”）都会引发错误。

生成带参数二维码领取卡券的两个关键步骤

实现用户扫码后自动跳转并领取卡券，并不是调一个接口那么简单。核心流程分为两步：首先是生成二维码凭证，其次是落地页的权限校验与SDK调用。

• 生成二维码ticket：调用create_qrcode接口时，action_name必须设置为“QR_CARD”，并且action_info里指定的card_id必须是已经审核通过、处于生效状态的卡券ID，草稿状态的卡券是无法生成领取二维码的。
• 前端JS-SDK权限校验：在落地页（例如/card/receive?ticket=xxx）中，想要调用wx.chooseCard让用户选卡领取，必须先通过config接口注入权限签名。这里的关键是，计算签名所用的jsapi_ticket、nonceStr、timestamp必须与后端生成签名时保持完全一致，否则会提示“invalid signature”。
• 处理领取回调：用户成功领取后，微信服务器会向你在公众号后台配置的card_api回调地址发送通知。特别注意，这个回调使用的是HTTP POST方式，并且数据格式是原始的XML，不是JSON。在ThinkPHP中，需要用file_get_contents(‘php://input’)来获取并解析原始XML数据。

ThinkPHP 中处理卡券核销的坑：核销码不是 code 字段

这是卡券流程中一个典型的理解误区。很多开发者以为用户领取卡券后获得的那个code就是直接用于核销的码，结果调用核销接口时总是返回errcode:40037（无效的卡券code）。实际上，用户领取后得到的是一个加密的encrypt_code，必须经过解密才能得到真实的核销码。

• 先解密，再核销：需要调用https://api.weixin.qq.com/card/code/decrypt接口，传入access_token和encrypt_code，从返回结果中获取真正的code，这个code才能用于consume核销接口。
• 解密只能进行一次：同一个encrypt_code在微信侧只能被成功解密一次，解密后该码会被标记为已使用。如果重复解密，会返回errcode:48001错误。
• 核销状态需主动同步：卡券核销成功后，微信不会主动推送通知给开发者。你需要通过定期轮询用户卡券列表（getcardlist接口），或者在卡券事件回调中监听card_consume事件，来确认核销状态并更新自己的业务数据库。

总的来说，微信卡券功能链条长、状态多、接口分散，最容易出问题的地方就是“你以为参数对了，实际上格式或调用时机不对”。尤其是在encrypt_code解密和二维码ticket生成这两个环节，调试时强烈建议把每一步接口调用的原始请求和响应数据都打印到日志里，不要只依赖errcode判断，很多时候响应体里的细节信息才是解决问题的关键。