这段时间由于要进行微信公众号相关的开发，故而接触到了微信支付。老版本的V2公众号微信支付比较难搞，有些东西不够规范。新版本的微信支付统一了接口，文档也比较齐全，全部接入商户平台（pay.weixin.qq.com）。下面简述一下微信公众号现金支付的开发过程。
申请微信支付
首先，你要有个公众号，而且是已经经过认证的，这样才能开通微信支付功能。开通微信支付功能后，你需要有个财付通商户号，将商户号绑定到公众号上。我开发的时候，同事已经帮我申请好了公众号及微信支付商户号，一切仅需要根据API进行开发即可。这里碰到过一个坑，我们怎么都不不知道微信商户号为什么没有权限，还叫微信的同事检查了一下，说要将公众号和商户号绑定，并且要审核通过批准开通的支付方式（JSAPI，NATIVE等）才能进行开发。
NATIVE支付
微信的原生支付，是通过扫码，从微信的应用原生入口，如对话框，或者是二维码中进入。与之相对的是JSAPI支付，是从内嵌的浏览器中发起支付，然后在浏览器中有条件的进行支付。NATIVE的支付开发模式分两种，一种是商户通过微信制定的规则，生成一个商品售卖的信息，返回二维码给用户扫码，用户扫码之后，微信回调商户后台，后台正式下单，微信得到下单后让用户支付该单。第二种是商户平台预先下单，相关支付信息已经提交了微信，用户扫码之后进行支付该单，支付完后微信回调商户结果。二者之间主要的差别在于，用户扫描时临时下单还是商户预先帮用户下单，然后再支付。由于我们设计了一个中间的支付平台，我们自身并不知道商品的信息，这样的业务适合由商户平台下单，然后等待回调的方式，这样比较直观，如果是直接卖东西的商户，可以直接提供商品的二维码，那么直接展示商品二维码的方式会直观点，但两者的效果都是等价的，两种支付方式皆可。
采用模式二，向微信下单，将会得到一个prepay_id，还有支付的二维码链接，得到链接后，商户要将它生成为二维码，生成的方式多种多样，一种是通过将数据提交给第三方的网页接口（一个链接），让他们帮忙生成二维码，然后通过 标签嵌入到页面中。另外一种是使用别人已经封装好的库，直接将二维码绘制出来，渲染在页面中。二者各有利弊，前一种能够节省资源，但要求网络条件良好，服务稳定，后一种则在本地生成，比较迅速。用户扫描二维码，进行输密码鉴权后，则扣款，等待回调通知商户平台，一般这个时间不会太久，因为用户的页面也在刷新支付结果，以及时地给用户一个反馈。
JSAPI支付
如果在移动端，应用又部署在移动网页上，那么二维码的方式不太适合，虽然也可以长按识别二维码跳转支付，但是这样的体验很怪。一开始，我很不理解，为什么微信不能像NATIVE支付一样，返回一个链接到微信内嵌的浏览器中，然后直接跳转到该支付地址，进入支付页面。后来转念一想，如果任何网页都能直接弹到支付页面，有可能会造成滥用下单，并导致有人中招支付了。微信需要一个授信的入口，让用户进入支付界面。经过测试，微信在浏览器跳转该支付链接的时候，进入不了输密码的界面，原因就是我这个是浏览器里面没有认证微信身份的操作，而对话和二维码扫描则不同，是微信客户端的原生入口，已经自带了微信用户的身份信息等。JSAPI的支付方式就是一个鉴权并跳转的过程，首先前半部分和NATIVE扫码支付一样，先给微信下单，返回一些下单的基本信息（核心的有prepay_id），后台将这些信息告诉前端，让前端跳转到一个微信鉴权的地址，并带上这些信息和一个跳转地址，鉴权通过后会进入支付界面，支付完成后，微信回调商户后台，同时页面回到商户的页面，刷新本地订单状态，呈现支付结果。这里总共是一个三方的关系，微信客户端（商户前端），商户后台，微信后台，这三者之间的交互，最终会使得支付状态一致，至于微信后台背后的银联等东西，对我们商户开发者是透明的。
JSAPI的方式需要通过js脚本调用微信的接口，这个接口就是原生的入口，这样的设计虽然看起来不一样，但是其实和NATIVE统一了。而且下单和支付的逻辑是一样的，只是具体的鉴权和调起的方式不一样。微信 商户后台 有详细的文档。 此外，JSAPI需要在微信公众号填写授权支付目录，只有制定的目录下面才能调起支付请求，一个大平台肯定会考虑比较多可能的情况，从而做得稳妥一点，他们也可能碰到过一些场景，出过问题，才弄成现在这样的设计。
小结
这其中我们踩过很多坑，很多信息也没有办法从界面上获得搞得浪费了一些时间，最好的状态就是一次申请通过，各种该开的支付权限都开了，并且发现了微信公众号后台的一些bug，这条路并不顺利。而且基于微信，我们设计了一个微信支付和积分支付的混合支付平台，用于腾讯内部的支付场景。这里API的设计和安全方面的保障参考了微信和支付宝的设计，后面将会详细说说。
by bibodeng 2015-11-22
from http://ju.outofmemory.cn/entry/228396