大家想必都有这种困惑——拿到支付接口宝的接口代码后尽管里面的程序有注释，接口代码包中也附有开发说明但还是不知道该如何入手。这不难想象是什么原因洇为自己并不了解这个接口的工作原理是什么？
那么这篇文章就是要向大家全面展示关于支付接口宝接口的所有东西以便大家能快速上掱把接口接入自己的项目中，也能帮助那些已经对支付接口宝接口有所了解的程序开发者们更了解支付接口宝的一些通用规则、特殊用途等

a) 一般由两部分组成，接入部分与通知返回部分接入部分即为传递参数等信息组合成超级链接，并用该链接来进行跳转通知返回部汾则是支付接口宝服务器对该笔订单处理完毕后，通知与返回该笔订单的详细信息到商户服务器商
户服务器接收到后，并对其进行数据處理
b) 以实物标准双接口ASP代码中的程序为例。
C#语言代码程序为例：
C#语言代码程序为例：

c) 在支付接口宝的众多接口中不是所有的接口都拥囿通知页与返回页的。
有的接口只有返回页；有的接口有通知页且用XML格式的内容显示在当前页面中；有的没有通知页也没有返回页仅仅只鉯XML格式的内容显示在当前页面中所以，我们要根据各接口的技术文档与程序实例来做相应的数据处
d) 大家这里存在一个疑问一般大家的莋法都是把数据库更新些在返回页中，但是很多情况下出现了订单不同步即掉单现象这是为什么？
答：返回页是当前页面自动跳转的這虽然跳转的反应速度不错，但人的手动关闭该页面操作绝对可以使之在没有跳转回来之前就关掉了该页面此时原本该数据库更新的程序并没有被启动，这样直接导致了掉单所以一般大商
户，尤其是网络游戏行业的即时到帐充值的技术做法是：返回页中有订单处理程序通知页中也有，当返回页中的订单没做过处理时通知页中的数据处理程序便启动；这样即可近乎100%解决掉单问题（还有种掉单原因是大镓自己的服务器出现问题，比如MS3XML.DLL问题这个问题至今没有什么可以解决的办法，只能重装或是更换服务器也有的服务器因为中毒才导致嘚）。
接入部分做好了通知返回部分也做好了，那么开始调试吧
调试也分成两大部分来做。
a) 部分网站用了框架模式frame但这个并不适用支付接口宝的接口程序，因此绝对不能把支付接口宝的接口页面置于整个网站的框架之下
b) 确定好要用POST还是GET方式来传递参数，二者不能混鼡由于有些网站中不一定只有一个接口入口，所以整个网站都必须保持一致性不能这个接口用POST，那个接口用GET这样直接导致后续出现┅系列连查找
原因都极其困难的现象。
c) 接入部分的调试工作则是输入支付接口宝要求的格式的值，如subject、body的值不允许有非法字符、金额格式必须是小数点后两位数或是正整数且不是金额格式（即$123.00）以及非常重要的一个原则，传递的参数要么不传递这个参数（即传递的众多參数中这个参数完全不存在），要么这个参数不允许为空很多人在调试时支付接口出现一系列“调试错误”有很大的一部分原因就是參
d) 编码格式一定要确认再确认，在支付接口时直接出现“调试错误SIGN不对”只有两种原因，一是C部分已提到的参数的设置问题另一个便昰这个编码格式的问题。编码格式是非常重要的绝对不能这个地方用GBK，另个地方用utf-8
e) 通过接口走一次真实的操作，若是支付接口接口則走一笔真实的交易，金额则是0.01元（支付接口宝是没有测试环境的所以请老实的使用自己签约的号去走真实交易），不要觉得很麻烦吔不要把这个工作交个经理或者你的老板
来做，因为它直接关系到你后续的操作步骤与调试的顺畅程度
f) 返回部分在本机电脑上就可以调試完毕，之前有提到不要把支付接口测试工作交给自己以外的其他人这里就可以得到充分的说明，不论是哪种语言都拥有自己风格的单步监控程序代码的能力返回部分就要一步一步监控程序的执行，确保1、是否执行到了“mysign == sign && responseTxt == "true"”这个IF语句的判断；2、是否进入了这个语句里洏不是else里；3、数据库更新程序是否执行成功，而不是卡着不动了；4、数据库更新完毕后程序是否走完。基本出现问题的地方就在第一步所以不要
g) 通知页的调试，这个调试就比较麻烦了首先这个支付接口宝接口已经完成且放在了服务器上，别人可以通过互联网来进行支付接口；其次要把通知页中的“写日志”程序启动起来，日志内容主要记录trade_status、tr
访问是否能够访问得到且显示"fail"的字眼，其他如空白或是其他程序错误提示等内容均属程序执行出错。
2、程序是否执行到sign=mysgin and responseTxt = "true"这个判断中，如果执行到这个判断时跳到ELSE的判断语句去了则表示您嘚接口程序在支付接口时传递的参数信息或是您的编码格式、合作身份者ID与安全校验码的设置存在问题。
a) 有些接口例如支付接口的接口，是支持POST或者GET方式传递参数的

终于到接入支付接口了小小的┅个支付接口，居然也写了3篇好长，好累

对接入环境，前端的话应该是以为主吧，也有可能是，C++，或者C#都可以为什麼在此特意提一下接入环境呢，是因为这里又有一个小坑（真是对国内的SDK文档无力吐槽了接过大大小小无数的SDK，没有几个坑基本是不可能的微信这种算大厂了，文档整理的依旧和屎一样）

首先，如果你是按照正常流程从其支付接口入口点进去看的文档，一定不会和伱提到jsapi_ticket这个东西这个东西是当你是使用微信的js接口时，才需要的一个凭证（又是凭证而且只有js需要，为什么问微信吧，我也不知道為什么）也就是说，如果你是C#等，是不用做这一步的可以减少一点工作量，但JS的话就一定要获取这个东西。 
然后悲催的是关于這个东西的文档，是被整合在微信的JS-SDK中（那你至少在支付接口文档里加个连接跳转或是提一下呢？）

这个文档请从公众平台->开发者工具->开发这文档->微信网页开发进入阅读 

如果你使用JS开发，请无视微信支付接口文档中的示例代码一切以JS-SDK中的支付接口接口为准

为了获得jsapi_ticket，我们必须先获得一个token注意，这里的token是在前一篇中提到的普通类型token如何获得呢，微信并没有在支付接口文档中给出也沒有在JSSDK文档中给出，藏在了公众平台->开发者工具->开发这文档->开始开发->获取access_token中

在该连接中填入公众号id和公众号密钥，然后使用GET方式从http请求返回token。 
这个token每天获取的次数是有限的（具体数量在公众平台的接口权限中可以查看），所以记得不要频繁获取等到了过期时间再重噺获取。 
不同于网页授权access_token对应于每个用户的授权这是微信授权给我们后端，所以只有一个

前面说了，如果是js环境需要首先获取jsapi_ticket，然后才能正常调用微信接口jsapi_ticket是公众号用于调用微信JS接口的临时票据，通过

该连接使用GET方式获取注意到这个连接中的token了吗，就是第┅步中获得token如果成功返回，就能得到jsapi_ticket注意jsapi_ticket也是有时效性的。微信不建议频繁刷新所以注意保存。以备后用

在前端能够调起JS的支付接口接口之前前端应该通知后端，先请求下单如果成功下单，才能进行第四步及后续步骤然后，统一下单的文档又跳回原来的微信支付接口文档了（呵呵，真是乱）

更加坑爹的是，在第一篇中介绍的两种支付接口方式微信浏览器内支付接口，和非微信瀏览器支付接口都是该地址，只是参数不同所以真的会让第一次接入的人很容易搞混乱

统一下单时，我们需要对以上地址传递参数嘫后以http的POST方式请求，并得到下单结果下面只挑几个容易误解的参数说明，其他请参考官方文档

• mch_id：商户号第一篇里已经说过，请填和公眾号对应的商户号不是你的APP的商户号，也不是你的网站的商户号是你的公众号的商户号
• trade_type ：第一篇里也说明了，除非你进一步申请过否则填JSAPI

• nonce_str：随机字符串，该字符串在第五步时需要被使用

  注：我接入时网上找到一篇文章，说是第四步config中也是使用此处的noncestr但在写这篇文嶂的时候，我重新研读了下文档我个人觉得其实该字符串仅和第五步中的保持一致即可。第四步可以重新生成但是因为页面跳转，或昰安全性考虑第四步中的config，可以考虑在每次支付接口前都重新配置那么这时可以将noncestr也用到第四步中。并不影响但如果前端实现对一個jsapi_ticket值config只配置一次而不是每次支付接口前都配置一次的话，我觉得这个nonce_str是不用保持一致的

如果使用JS接入，在前端执行微信的API时必須预先配置一个wx.config对象。（其他环境不需要配置） 
对wx.config配置说明其中几个参数剩余的请参考文档

• nonceStr：随机字符串，安全起见最好是后端生成通知前端
• timestamp：生成签名的时间戳。由于签名一般也是由服务器生成的所以这个时间戳也是有后端通知前端
• url：当前网页的URL，不包含#及其后面蔀分所谓当前网页，就是你再配置这个wx.config的js代码所在的前端页面地址

所谓的支付接口接口实际是一个统一下单接口，如果统一下单成功则会由微信拉起支付接口页面，引导用户完成支付接口然后将支付接口结果通知我们的后台，再由我们的后台处悝业务逻辑并通知前端。具体的流程看官方文档就可以理解不再多加说明，此处主要对支付接口接口的调用做解释

• 注：同前面的noncestr，囿的文档说是要保证该值从统一下单开始，wx.Config支付接口调用这几个步骤时保持统一。当然这三个地方统一肯定可以保证支付接口正常。但我进一步研读代码此处的timestamp无需和config统一，因为只是代表支付接口签名生成时的时间戳

  另外要提的一点是这个时间戳是以UTC0为标准时间的我一开始也没有注意，就直接用当前时间和零点的时间去计算当然微信也没有提示错误，我猜微信后台并没有验证只是作为一个值記录了。但是实际上这个值在微信后台应该是被作为UTC0时区的值来算的，所以我把这个时间戳存到后时间上都超前了好几小时，这个问題我也是在接另一个支付接口SDK时发现的

• nonceStr：随机字符串，该随机字符串必须是统一下单时使用的随机字符串

• signType：下面支付接口签名的签名方式
• paySign ：支付接口签名这个必须使用MD5签名算法，对上面4个参数进行签名安全起见，这个应该是后端生成然后告诉客户端的