微信支付于 2013 年正式发布，一路走来，内测团队能明显感觉到，微信支付的接口稳定程度有质的提升，围绕支付相关的场景也配备了对应的接口。
微信小程序的发布，随机附送了一个微信支付模块，该模块使用起来的情况如何？现在就来告诉你。
业务流
-
微信客户端内的网页支付 (JSAPI)
-
扫码支付 (PC 端，移动支付终端)
-
刷卡支付 (支付终端扫描)
-
app 支付 (iOS, Android)
各种支付交互流程可通过微信支付文档进行查看，在此不赘述
1. 支付发起
但在小程序内测期间，还没有「统一下单」的概念。HTML 5 应用发起支付需要直接通过前端构造参数来发起（不经过后端验证），很容易造成支付凭证泄露等安全问题。
该优化带来以下好处:
-
尽可能让开发者不犯低级错误，造成财务损失。
-
简化构造支付参数的复杂度，所有支付方式可共享一个支付后端接口。
通过「统一下单」获取到相对应 prepay_id 或者 code_url 等参数，即可通过各种支付模式的 SDK 来进行微信支付的发起。
2. 支付结果接收
微信支付发起完成后，微信还需要提供一个通知系统，以便及时让应用知道用户已经完成支付，进行下一步的业务操作。
通知方式为一个 POST 请求，payload 为支付的状态信息，以及支付订单信息。
需要注意的是，必须对通知参数进行签名验证，以确保安全。
进行签名验证时，除去签名字段（一般参数名为：sign）不需要参与签名外，其余所有接收到的参数均需要参与签名。
3. 周边接口
-
查询订单
-
取消订单
-
申请退款
-
查询退款
-
下载对账单
具体使用可以参考微信支付文档，根据自身业务情况适当的进行采用。
在开发过程中，容易掉进去的一些坑。
1.支付凭证
小程序的微信支付需要单独去申请，因为小程序是有独立的 appid，不能使用以前的支付账户。
2. 统一下单参数
3. 签名方式
微信公众文档有很多 SHA1, MD5 的签名要求，微信支付相关的签名，暂时都是使用 MD5。
小程序端在发起微信支付的时候，是通过以下方式来进行发起:
-
timeStamp
-
nonceStr
-
package
-
signType
OK，按照签名算法得到的签名，去发起支付，居然提示失败了。
经过与微信对接人员沟通后，参与签名的字段还需要加上appId。
备注：prepay_id 通过微信支付统一下单接口拿到，paySign 采用统一的微信支付 Sign签名生成方法，注意这里 appId 也要参与签名，appId 与 config 中传入的 appId 一致，即最后参与签名的参数有 appId、timeStamp、nonceStr、package、signType。
4. timestamp 类型
小程序端发起微信支付的方式已经贴在上面了，但没那么简单，继续贴文档说明。
文档告诉我们 timeStamp 应该带着 int 类型传入。
结语
总体上，小程序接入微信支付还是比较简单的，没有过多复杂的设置。
如果之前开发过微信支付后端的开发者，还可以复用同一个支付模块。
微信文档的编写不严谨，使得开发的舒爽度严重被削减。相信随着时间推进，文档会慢慢完善，毕竟以前也是这么过来的。
