【商城应用】扫码支付体系设计

以你之姓@ 2022-04-13 09:30 328阅读 0赞

大的商城一般会有线下门店加盟，例如B2B平台，在平台采购，然后将采购的数据同步到线下门店进行买卖。所以线下门店一般都会有门店pos系统，采用pos进行扫码支付，但是今天跟大家说的不是pos门店的扫码支付，而是采用app二维码收款功能。

**扫码支付方案**

**方案一：**一种比较常见的方案是，我们app上面生成一个收款二维码，然后用户采用微信或者支付宝进行扫码支付。但是这种方式弊端是：系统没办法获取买家的订单信息，比如我们想每完成一笔交易，就需要给买家发放对应积分，那用这种模式就很难做到了，而且这种扫码支付也会涉及到手续费的问题。

**方案二：**付款方和收款方都必须安装平台app，简单的说就是付款用户和收款用户，都必须是同一个app。这样做的好处是：所有的请求全部走的是系统本地，每一个步骤都是可控的，可以获取到任何信息。今天给大家介绍的，也是这种扫码支付模式的。

![36037][]

**收款二维码生成过程：**

收款二维码分成两种：动态二维码和静态二维码。动态二维码的意思是：收款方设置一个固定收款金额，用户一扫只能支付固定的金额。静态二维码的意思是：收款方没有指定金额，扫款方可以输入任意的金额。

收款二维码本质其实就是一个链接，静态二维码只有收款用户的id，动态二维码会有收款用户id和收款金额的信息。这边大家可能也看到了，如果付款方扫码的时候，下们会出现支付中的状态，付款完毕之后就显示支付成功，实现这种方式有两种方法。

![36205][]

**状态推送设计：**

状态推送有两种模式：推送模式和轮询模式。

**推送模式：**采用激光推送的模式，当有买家进行扫码的时候，推送一条支付中的消息，扫码成功再推送一条支付成功的记录，收款方收到消息的时候显示对应的状态就可以了。采用这种模式的好处是：消息及时性，不损耗性能，坏处就是推送存在遗失的情况，有可能收不到消息。

**轮询模式：**收款方每间隔一段时间，就去服务器请求获取状态数据。采用这种模式好处是：消息不会遗漏，只要控制好间隔时间，也可以做到基本实时获取，缺点也很明显，会影响服务性能。如果同时多个商家一起收付款的时候，就是造成高并发请求。

<table> 
 <tbody> 
  <tr> 
   <td>&nbsp;</td> 
   <td> <p>优点</p> </td> 
   <td> <p>缺点</p> </td> 
  </tr> 
  <tr> 
   <td> <p>推送模式</p> </td> 
   <td> <p>1.消息及时性，马上推送即可马上获取。&nbsp;2.因为采用的是第三方推送服务，所以不损耗任何服务器性能。</p> </td> 
   <td> <p>1.推送存在遗失的情况，有可能收不到推送消息。&nbsp;2.取决于第三方推送的性能，可靠性不高。</p> </td> 
  </tr> 
  <tr> 
   <td> <p>轮询模式</p> </td> 
   <td> <p>消息不会遗漏，只要控制好间隔时间，也可以做到基本实时获取。</p> </td> 
   <td> <p>会影响微服务的性能，如果同时多个商家一起收付款的时候，就是造成高并发请求。</p> </td> 
  </tr> 
 </tbody> 
</table>

**扫码支付过程：**

用户扫码支付相关而已会比较简单，主要是app那边进行二维码识别。首先进行二维码识别，如果是静态二维码就需要用户手动输入金额，如果是动态二维码，就直接显示需要支付的金额即可。然后用户点击对应的付款方式，输入支付密码就支付成功了。

![36111][]

**扫码数据流动过程：**

扫码成功之后会跳转到一个付款页面，在用户点击付款的时候会生成一个扫码付款的订单，这个订单是未支付状态，用户选择对应的付款方式支付完成之后，这个扫码订单状态就会变成付款成功，扫码支付的流程也就完成了。这边需要做一点限制，如果是同一个页面反复点击支付按钮，不应该产生多个扫码订单。上面说到的收款状态，其实就是根据支付状态来的。

![36125][]

**扫码支付流程图：**

![36201][]

**技术注意点：**

*  扫码支付的时候，一定要查询一下用户当前余额是否大于付款金额，不满足则返回余额不足。
 *  如果app没有做账户在线个数限制，一定需要做分布式锁，来限制同一时刻只能有一个人支付。
 *  出于安全考虑，支付的手机验证码要设置时效性，比如超过一分钟后验证码失效，必须重新获取。
 *  需要做一个无效页面，有可能扫码方会扫一个非收款码的二维码，所以要做好意外处理。
 *  支付失败也要做错误标识，支付状态显示为支付失败。
 *  每次进入二维码收款页面的时候，获取当前之后的支付状态。
 *  扫码支付金额前端需要做一定的校验，比如不能大于某个值且不能小于某一个值。
 *  扫码需要做行为校验，校验是否是我们系统app发起的扫码支付。

**总结：**

今天介绍的这种方式，最大的局限性就是：买家必须安装平台app才可以。这种方式的好处是：支付可控，每一个过程我们都可以获取到对应的数据，还可以进行app引流。缺点也显而易见：支付需要下载app，一定程度上面会造成用户流失或者减少客单量。所以在设计方案的时候一定要充分考虑方案的优缺点，最后选取最合适的方案。

**要更多干货、技术猛料的孩子，快点拿起手机扫码关注我，我在这里等你哦~**

![70][]

[36037]: /images/20220413/3fa06cd831c347b78b3fcccc1c01443a.png
[36205]: /images/20220413/24fd7165b01f41fd84e803f6985b3e0a.png
[36111]: /images/20220413/bf1f4c71afc64a3394eb063e23733a9f.png
[36125]: /images/20220413/96dbf26c762b44b0ace0231cfd94bf11.png
[36201]: /images/20220413/e63e322b27894453bf54466feeecf6ff.png
[70]: /images/20220413/3450d23ce3b14bf885eb01d324ef8a40.png