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

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://cloud.tencent.com/developer/article/1434180

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

扫码支付方案

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

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

收款二维码生成过程：

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

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

状态推送设计：

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

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

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

扫码支付过程：

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

扫码数据流动过程：

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

扫码支付流程图：

技术注意点：

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

总结：

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

​