关于支付模块，首先引入两个概念，订单和支付流水。
订单，比如我们每下一单，就有一个订单。
支付流水，我们每支付一次就会有一次支付流水。
即：每个订单允许被支付多次。
问：为什么每个订单允许被支付多次？
答：因为每次的支付不一定会成功啊。所以才存在一个订单允许被支付多次。但是这样的话也带来了副作用，就是如果第三方收款的回调通知如果迟到，会出现用户重复支付这个情况，后续需要还要写定时任务进行退款。
进入主题：
首先关于支付渠道列表设计：
支付的渠道一般分为三种：微信，支付宝，银行卡，余额支付，大额支付。
设计技巧：在接口中，我们返回的列表中可设计为：
上传订单号，返回可以使用的支付渠道让客户进行选取。
余额支付：即有一些公司会使用第三方的电子钱包，所以会出现一个虚拟的账户，账户上的金额为充值所得，主要解决较大额度的支付。
大额支付：这个是博主自己定的，比如使用转账到电商平台公户，然后通知平台帮助其下单。
app端：
微信，支付宝：
一般使用微信和支付宝支付，把订单号传至服务器，服务器使用微信和支付宝的sdk打包数据格式，然后返回给app端，app端带着这些参数，调起本地sdk，打开微信和支付宝进行支付，返回app 端后，app调起对应的sdk，即可以检查是否已经支付，跳转支付结果展示页。
银行卡：
银行卡同样是把订单号上传至服务器，然后获取打包返回的网址，然后app端打开web view打开网址，用户在该页面上进行支付，支付之后，app端拦截支付完成（支付完成不等于支付成功）后跳转的地址，每5秒访问一次服务器的中订单是否支付的接口，得到结果，跳转到展示页面。
服务器：
1.在用户选取对应的支付渠道，进行数据打包，每一次支付生成一条支付流水，返回给app端，让app端带着含有订单参数的数据去支付。
2.用户在支付完成之后，第三方（无论银行和支付宝微信都一样），会回调服务器事先埋藏好的回调通知地址（主要用于接收支付结果的用途），服务器得知，进行支付后操作，比如，增加订单，增加统计，增加xxx。
接口设计如下：
1.支付渠道列表
2.选择支付方式（主要是打包返回给app让其带上数据）
3.检查订单是否支付（该服务器接口打包第三方检测订单是否支付的接口）（避免由于第三方服务器繁忙导致延时，直接导致客户重复支付发生）
4.回调地址
4.1回调地址设计，核心功能是确认好当前支付流水已经支付.
4.2通知消息队列，进行支付完成后操作，如：支付成功消息推送，订单统计。（可使用消息队列）