关于支付模块,首先引入两个概念,订单和支付流水。
订单,比如我们每下一单,就有一个订单。
支付流水,我们每支付一次就会有一次支付流水。
即:每个订单允许被支付多次。
问:为什么每个订单允许被支付多次?
答:因为每次的支付不一定会成功啊。所以才存在一个订单允许被支付多次。但是这样的话也带来了副作用,就是如果第三方收款的回调通知如果迟到,会出现用户重复支付这个情况,后续需要还要写定时任务进行退款。
进入主题:
首先关于支付渠道列表设计:
支付的渠道一般分为三种:微信,支付宝,银行卡,余额支付,大额支付。
设计技巧:在接口中,我们返回的列表中可设计为:
上传订单号,返回可以使用的支付渠道让客户进行选取。
余额支付:即有一些公司会使用第三方的电子钱包,所以会出现一个虚拟的账户,账户上的金额为充值所得,主要解决较大额度的支付。
大额支付:这个是博主自己定的,比如使用转账到电商平台公户,然后通知平台帮助其下单。
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通知消息队列,进行支付完成后操作,如:支付成功消息推送,订单统计。(可使用消息队列)