卡券API对接自动发货，搭建时容易忽略的环节

做卡券API对接自动发货，很多人以为拿到接口文档就能搞定，实际上线后才发现一堆坑。今天不聊高大上的架构，就说几个搭建时容易忽略的环节，都是我自己踩过或帮别人排查过的经验。如果你正准备接卡券API，建议先看完这篇。

回调地址校验不严格，订单状态容易不同步

对接卡券API，回调是核心。但很多开发者只验证签名，不校验回调里的订单号、金额和商品ID是否与本地订单一致。结果呢？别人伪造一个回调，或者平台重复推送，系统就发货了。更常见的是回调地址没设置正确，导致支付成功但卡券没发出去。我见过一个朋友，回调地址写成了http，线上却是https，结果回调全部丢失，用户投诉一堆。

正确做法是：回调地址必须支持HTTPS，并且要对订单状态做幂等处理。也就是说，同一个订单回调多次，不能重复发货。另外，回调返回给平台的响应要固定格式，比如返回“success”字符串，别返回JSON，否则平台可能认为回调失败，反复重试。

库存扣减与超卖防护，比想象中更重要

很多卡券API对接自动发货的初稿里，库存扣减是查一下库存，够就减，然后发货。但如果并发高，两个请求同时查到库存为1，就会超卖。尤其做影视会员这类热门商品，活动一上线瞬间几百单，库存直接变负数。如果你做的是影视会员类目，可以参考站内影视会员栏目的经验。

解决思路很简单：用数据库的原子操作，比如UPDATE stock SET count = count - 1 WHERE count > 0，影响行数为0就说明没库存了。别用“先select再update”这种非原子操作。另外，如果卡券是批量导入的，最好在内存里做预扣减，或者用Redis分布式锁。库存这块，宁可少卖，不能超卖，超卖补货的成本远高于少赚一笔。

日志记录和异常告警，别等出事了才后悔

搭建时最容易忽略的是日志。很多人的代码只记录成功，不记录失败。结果某天自动发货停了，用户收不到卡券，你还在被窝里。等到第二天看数据才发现，但已经损失惨重。

我习惯在关键节点打日志：收到订单、回调校验、扣库存、调卡券平台API、发货成功/失败。每个节点带上订单号和耗时。同时配置告警，比如连续3次发货失败就短信通知。别小看这个，自动发货最怕的就是“静默失败”——平台没返回错误，但卡券没发出去。这种问题没有日志很难排查。

对接乐辰数卡这类平台时，注意幂等性设计

如果你是通过货源平台做卡券API对接自动发货，比如乐辰数卡（https://lcsup.com），除了上面几点，还要注意幂等性。因为货源平台可能因为网络超时让你重试，但你不知道上一次请求到底成功了没有。这时候需要生成一个唯一的请求ID，重试时带上同一个ID，平台端就能识别并返回原来的结果，避免重复扣款或重复发卡。

另外，对接前一定要读清楚文档里的错误码，尤其是“处理中”这种状态。别把“处理中”当失败，直接给用户退款，结果卡券又发出来了。这种事故很常见。如果你是企业采购场景，也可以看看站内企业福利栏目的采购建议。

总结

卡券API对接自动发货，搭建时容易忽略的环节其实不多，但每个都能让你线上翻车。回调校验、库存扣减、日志告警、幂等设计，这四块做好了，系统基本就稳了。希望这篇经验能帮你少走弯路。

常见问题

卡券API对接自动发货需要哪些准备？

需要准备一个已备案的域名和HTTPS证书，用于接收回调；一台服务器或云函数，保证接口稳定；还有卡券平台的API文档和测试环境。建议先在小流量下跑通全流程，再放开。

回调地址怎么设置才安全？

回调地址必须走HTTPS，并且只接受POST请求。在代码里要校验签名、订单号、金额和商品ID，同时做好幂等。返回给平台的内容固定为“success”，不要带其他字符。

自动发货失败怎么办？

先查日志，看是卡券平台接口超时、库存不足还是回调没收到。如果是接口超时，可以设置重试机制，但一定要用同一个请求ID。如果库存不足，要立即告警并暂停发货，避免用户下单后长时间无卡券。