做小程序开发的人，十有八九都要碰支付。没碰过的人觉得不就是调个接口嘛，碰过的人才知道，从申请商户号到真金白银进账，中间隔着一条河，河里有暗礁、有漩涡，还有一堆看起来不起眼却能把人绊倒的石头。这篇文章就把这条河从头到尾趟一遍，把那些坑、那些细节、那些文档里写得含糊但实际操作躲不开的环节，全给你摊开说清楚。

第一步其实不是写代码，是把自己“洗白”。微信支付要求小程序的主体必须是企业、个体工商户或者某些特定组织，个人开发者直接没戏。你打开微信公众平台，在小程序后台的“支付”菜单里点开通，系统会引导你去申请微信支付商户号。这个过程需要营业执照、法人身份证、对公账户或者法人个人银行卡，还要填经营场景、商品类目。别小看这个类目，你卖食品和卖软件服务用的类目不一样，审核严格程度也不一样。有人卡在这里半个月，就是因为营业执照上的经营范围跟选的类目对不上，客服来回打太极，换了类目才过。

商户号申请下来之后，别急着写代码，先把商户平台里的API密钥设置好。这个密钥是你和微信支付服务器之间通信的“暗号”，32位字符串，自己生成，自己保管。很多人图省事用123456这种，或者直接复制网上的示例，那等于把保险柜钥匙挂在门口。设置密钥的同时，还要下载商户证书，这个证书是双向认证用的，后面发起支付请求时必须带上。证书下载下来是一个压缩包，里面有apiclientcert.pem和apiclientkey.pem两个文件，记得放到服务器上安全的位置，别提交到Git仓库里，不然你的密钥和证书就全网公开了。

代码层面的第一步是获取用户的openid。小程序前端调用wx.login拿到code，把这个code传到你的后端，后端拿着code加上小程序的AppID和AppSecret去微信的接口换openid。这个openid是用户在你这个小程序里的唯一身份标识，支付、退款、查订单全都要靠它。注意，AppSecret千万别放在小程序前端代码里，那东西一旦泄露，别人就能冒充你的小程序干坏事。正确做法是把AppSecret放在后端服务器，前端永远只传code。

拿到openid之后，后端就可以组装支付参数了。你需要调用微信支付的统一下单接口，传过去的参数包括小程序的AppID、商户号、商品描述、商户订单号、金额（单位是分，别传元，传元的话金额直接少一百倍）、用户的openid，还有回调地址。这个回调地址特别关键，它是微信支付在用户完成支付之后通知你服务器“钱到了”的地址。很多人在这里犯迷糊，以为回调是给前端用的，其实回调是微信服务器直接请求你的后端服务器，跟你小程序的页面完全没关系。回调地址必须是一个公网能访问的HTTPS接口，不能带参数，而且返回给微信的响应必须是特定格式的字符串，不然微信会认为通知失败，然后每隔一段时间重试一次，最多重试好几天。

统一下单接口返回的是一串预支付交易会话标识，也就是prepayid。你的后端拿到这个prepayid之后，还要再生成一个签名，然后把时间戳、随机字符串、prepay_id、签名这些东西一起返回给小程序前端。前端拿到这些参数，调用wx.requestPayment，这时候用户手机上就会弹出那个熟悉的输入密码的界面了。

这里有个细节很多人忽略，就是签名的生成规则。微信支付所有接口的签名都是把参数按字典序排列，然后拼上你的API密钥，再做MD5或者HMAC-SHA256运算。参数拼接的顺序错了、多了空格、大小写不对，都会导致签名校验失败。我见过有人排查了一整天，发现是参数里多了一个换行符。这种问题微信返回的错误码是“SIGNERROR”，每次都让你怀疑人生。建议你把签名算法写成一个独立的函数，所有接口共用，然后在这个函数里加日志，把每次参与签名的原始字符串打出来，对比微信的示例，一眼就能看出哪里不对。

支付成功之后，钱并不会马上到你的对公账户。微信支付的结算周期一般是T+1，也就是说今天用户付的钱，明天才能结算给你。而且微信会从每笔交易里扣除手续费，费率根据你的行业和资质在0.6%到1%不等，餐饮、零售有时候能谈到更低。这些钱在商户平台里能看到明细，每一笔交易、每一笔手续费、每一次提现都有记录。提现的话，你可以手动操作，也可以设置自动提现，但自动提现的最低金额有要求，太少了提不出来。

再来说说退款。用户申请退款，你的后端要调用退款接口，传商户订单号和退款金额。退款接口是单独的一套签名规则，而且需要用到商户证书的双向认证，比下单接口更严格。退款不是即时到账的，微信会先标记退款中，然后异步通知你退款结果。这里最容易出问题的场景是部分退款，用户买了两件商品退一件，你的退款金额必须小于等于原支付金额，而且退款次数没有硬性限制，但每次都走同样的流程。还有一点，退款必须退到原支付渠道，用户用微信零钱付的就退回零钱，用银行卡付的就退回银行卡，你没法指定退到别的地方。

说一下上线前必须做的自查清单。第一，回调接口要做幂等处理，微信可能因为网络原因重复通知你，你不能因为收到两次通知就给用户加两次余额。第二，金额必须用整数分存储和计算，前端展示的时候再转成元，否则浮点数精度问题会让你差出几分钱。第三，支付结果要以你的后端收到回调为准，不能只看前端wx.requestPayment的返回值，因为用户可能支付成功但前端网络断了，收不到成功回调。第四，有个沙箱环境叫“模拟支付”，微信提供了一套测试用的商户号和专用金额，比如1分钱或者特定数字，在正式上线前一定要在模拟环境里把整条链路跑通，包括下单、支付、回调、退款，全流程走一遍。

微信小程序支付这条路，说难不难，说简单也不简单。难的是那些藏在细节里的坑，比如签名少个换行符、金额单位搞错、回调地址写错、证书权限没设置对。简单的是，只要你按照官方文档一步步来，别自作聪明，别跳步，基本上都能顺利走通。我见过太多人一上来就急着写代码，结果卡在商户号审核上，或者在签名校验上耗了两天。磨刀不误砍柴工，把前置准备工作做扎实，把每个环节的边界条件想清楚，支付功能其实也就是几个接口来回调用而已。但真到了上线那一刻，看着后台第一笔真实交易到账，你心里那种踏实感，是写一百个普通页面都给不了的。