唐山小程序支付对接：踩过的坑与实战解法

上周帮唐山本地一个做社区生鲜的客户收尾小程序，最后卡住的不是页面也不是接口，而是支付。客户老板原话是：“东西都能下单了，钱收不进来，这不白做吗？”这话挺实在。支付对接看着就是调个接口，真上手才知道坑不少。这篇就把我在唐山做小程序开发时支付对接的经验捋一遍，尽量说人话。

先把资质和商户号理清楚

很多唐山做小程序的客户一上来就问“能不能直接收款”，答案是能，但你得先有东西：

• 企业或个体工商户营业执照（个人主体的小程序开不了微信支付）
• 微信支付商户号，和对公账户或法人银行卡绑定
• 小程序 AppID 与商户号完成关联，并在商户平台确认授权

这一步最容易拖时间。我见过唐山本地一家做建材的客户，营业执照经营范围和小程序类目对不上，审核被打回两次，前后多等了一周多。所以我的习惯是：项目启动第一周就催客户去申请商户号，别等代码写完才想起来。

下单、签名、回调，三步走

现在微信支付主推 V3 接口，签名用 SHA256-RSA，比老版 MD5 那套规范，但证书管理要细心。核心流程其实就三步：

1. 服务端统一下单

小程序端不碰密钥，所有下单请求走自己的服务端。以云开发为例，云函数里调统一下单接口：

const pay = await cloud.cloudPay.unifiedOrder({
  body: '唐山生鲜-蔬菜套餐',
  outTradeNo: orderNo,
  spbillCreateIp: '127.0.0.1',
  subMchId: MCH_ID,
  totalFee: amount, // 单位：分
  envId: 'your-env-id',
  functionName: 'payCallback'
})
return pay.payment

注意金额单位是分，我第一版就写成元，测试时付了 0.01 元还纳闷怎么对不上账。这种低级错误别笑，真发生过。

2. 小程序端拉起支付

wx.requestPayment({
  timeStamp: res.timeStamp,
  nonceStr: res.nonceStr,
  package: res.package,
  signType: 'RSA',
  paySign: res.paySign,
  success: () => { /* 跳订单详情 */ },
  fail: (err) => { /* 提示用户取消或失败 */ }
})

这里有个细节：success 只代表用户完成了支付动作，不代表钱到账。真正的订单状态必须以服务端回调为准，前端别自作主张改状态。

3. 支付回调要幂等

回调可能重复推送，必须做幂等处理。我的做法是回调里先查订单状态，已支付就直接返回成功，不重复发货、不重复加积分。唐山有家做本地烘焙的客户，早期没做幂等，结果一单蛋糕券发了两张，虽然金额不大，但账对不上很难受。

几个实际踩过的坑

• 证书路径问题：V3 接口要加载商户私钥，云函数里路径和本地不一样，建议把证书内容放环境变量，别硬编码文件路径。
• 回调地址必须是 HTTPS：本地调试用内网穿透，别拿 http 地址去配，配了也收不到。
• 退款别忘同步：退款回调同样要处理，订单状态、库存、优惠券都得回滚，这块逻辑最好和支付回调写在一起统一管理。
• 测试环境用沙箱或小额：正式环境别拿大金额试，1 分钱跑通全流程最稳。

给唐山本地客户的几句实在话

做小程序支付，技术本身不算难，难的是资质、对账和售后。我在唐山做小程序开发和 APP 开发这几年，接触的本地客户多是餐饮、零售、社区服务这类，支付场景不复杂，但特别在意“钱对不对得上”。所以我的建议是：

• 找开发方时，问清楚支付回调、退款、对账这几块怎么处理，别只看能不能付款；
• 商户号自己保管好，别把密钥直接丢给外包就不管了；
• 上线前用真实小额跑一遍下单、支付、退款全流程，截图留档。

我是知码客，专注小程序和 APP 开发，平时就在唐山这边跑客户、写代码。支付对接这种事，说到底是把细节做扎实，让每一笔钱都清清楚楚。如果你也在唐山做小程序，卡在支付这一步，欢迎一起聊聊。