深度解读聚合收款码背后的原理（完结）

Hello，我是二哥呀！

继续跟大家分享一下支付相关的话题：聚合收款码的支付原理，这也是我这大半年来一直

在做的项目。

1419561-20200928084835878-1900620469.jpg

1419561-20200928084836141-145624609.jpg

另外，这种个人的收款码通常还有单日收款的上限，比如支付宝单日上限 500 元。

有了需求，自然会有聪明人人想到解决方案，于是有了聚合收款码产品解决方案,如下

图。

1419561-20200928084836293-1865437191.png

用户选择任一支持的客户端扫码，都能完成支付，再也不用纠结扫错码的尴尬。

有没有很神奇？其实底层原理很简单，看完你就明白了，下面就让二哥带你解密聚合收款

码的底层原理。

付宝渠道出发，简单介绍这个过程将会使用的支付方式。

1419561-20200928084836565-788134085.png

其中付款码支付在前两篇文章完整介绍过，这里不再介绍，感兴趣的小伙伴可以回头去看

看这两篇文章。

44920c8c-bcdc-472e-b26d-7d35ef98ac73.png

扫”完成支付的模式。该模式适用于 PC 网站支付、实体店单品或订单支付、媒体

广告支付等场景。

weixin://wxpay/bizpayurl?sr=123456

1419561-20200928084836698-1766666089.jpg

这种支付方式可以应用在 PC 网站购物场景，比如说英雄联盟官网购买相关游戏道具：

1419561-20200928084836847-1798138956.jpg

信 Native 支付这种支付方式呢？

答案是可以，但是不适合，产品体验不太好。

至于原因，不要急，接下去看就会明白。

JSAPI 支付，又被称为公众号支付，名词解释引用一下官网介绍：

具体业务流程如下：

1419561-20200928084837003-1217243690.jpg

日常生活中，很多应用场景使用这种支付方式，比如说：极客时间公众号上购买课程

1419561-20200928084837175-1741244885.jpg

能，以此获取用户的 openid。

1419561-20200928084837323-1269436908.jpg

聚合收款码核心原理

了解完聚合支付的所需要的底层支付方式，下面我们来了解一下聚合收款码的核心原理。

聚合收款码业务流程如下：

1419561-20200928084837592-1240017064.jpg

这个收银台页面可以自适应，不同 APP 显示不同的样式，比如支付宝打开收银台显示支

第二步，用户在收银台输入金额，点击支付之后将会唤起 APP 的支付弹窗。

好了，观察这个流程，我们可以发现扫码之后，后台应用需要识别出当前 APP 到底是微

信还是支付宝。

那如何判断当前使用的 APP 呢？

HTTP 请求，而 HTTP 的请求头将会携带 User-Agent(UA)，用来标识用户代理软件的应

用类型、操作系统、软件开发商以及版本号。

支付宝

UCBrowser/11.5.0.939 UCBS/2.10.1.6 Mobile Safari/537.36

AliApp(AP/10.0.15.051805) AlipayClient/10.0.15.051805 Language/zh-Hans

MQQBrowser/6.2 TBS 043220 Safari/537.36 MicroMessenger/6.5.8.1060

NetType/4G Language/zh_CN

这里需要注意了，不同型号的手机，不同的版本 APP，User-Agent 不一定会一样，其实

我们只需要判断是否包含某些关键字即可，比如说只要 User-Agent 包含

下面使用 Java 代码为例：

String userAgent = request.getHeader("user-agent");

if (Objects.equals(userAgent, "AlipayClient")) {

// 支付宝

} else if (Objects.equals(userAgent, "MicroMessenger")) {

}

拿到相关参数之后，唤起支付。

准确来讲，支付宝那边 JSAPI 支付官方名称为支付宝生活号支付。

码打开，唤起支付。

这样一来比较影响产品体验，降低支付的成功率。

链接。

那这里可以给大家提个小问题，聚合收款码是否可以使用支付宝当面付扫码支付接口那？

这是因为支付宝返回链接是一个标准 HTTP 连接，如下：

https://qr.alipay.com/xxxx

这个链接只要在支付宝内中打开，就可以唤起支付。

所以如果聚合收款码使用支付宝当面付扫码支付接口，收银台金额提交之后，当拿到支付

宝返回的支付链接，应用程序内只要使用 HTTP 302 跳转到支付链接，就可以唤起支付宝

支付。

那这样实际上聚合收款码底层使用支付方式就有了两种方案：

那如何选择那？

主要是因为只要 302 跳转唤起支付宝支付，就会关闭我们收银台页面，这样一来整个微

信支付与支付宝支付流程就不太一样了

其次，当用户支付成功之后，JSAPI 支付还可以跳转到一个成功页面，这个页面我们可以

支付结果展示，或者骚一点，还可以挂些广告，或者引流其他公号上。

但是如果使用付宝面付扫码支付，支付完成之后，页面就被关闭了，就没办法完成支付页

面跳转。

聚合收款码核心流程

介绍完原理，下面主要介绍一下市面上主流聚合收款码业务流程，其实聚合收款码可以分

为三类：

• 静态聚合收款码

• 动态聚合收款码

• 银联静态二维码

静态聚合收款码就类似如下这种，需要用户主动输入金额，可以无限次使用。

1419561-20200928084837726-948904977.jpg

而动态聚合收款码是只能使用一次，并且由商家指定金额，用户只要扫码就可以支付指定

金额。

这种应用场景比如 B 站购买大会员：

1419561-20200928084837895-1482620524.jpg

银联静态二维码其实功能上与静态聚合收款码差不多，但是它多了支持银联支付的功能。

除了这个以外，最主要的区别是银联静态二维码是银联发码，背后对应的地址是银联的地

址，类似如下：

https://qr.95516.com/00010000/xxx

静态聚合收款码流程

静态聚合收款码主要支付流程主要可以分为二步，第一步为登录授权。

1419561-20200928084838095-1989649474.jpg

无感知的。

画外音：如果是程序员的话，可能会感受到这个过程经过了多次跳转。

第二步，用户在收银台输入金额之后，应用内部将会创建相应的订单，然后再调用微

信/支付宝的 JSAPI 支付。

1419561-20200928084838224-844322765.jpg

另外，如果支付宝采用面付扫码支付这种支付方式的话，那么其实不需要第一步登录授权

了，可以直接跳到收银台发起支付。

1419561-20200928084838382-1257375540.jpg

动态聚合收款码流程

动态聚合收款码其实与静态收款码总体比较类似，只不过创建动态码内部已经创建了相应

的订单，后续流程与静态聚合收款码差不多。

1419561-20200928084838535-1889083978.jpg

银联静态二维码流程

其实跟静态聚合收款码一模一样的。

但是如果你使用支付银联支付的 APP 扫码，比如说各大银行的手机 APP，美团，京东

等，就会在这些 APP 内各自支付页面，然后完成支付。

我们银联二维码的功能，将会在银联后台报备一个跳转地址，比如说

https://www.heihei.com

后台根据规则拼接重定向地址。

拼接规则如下：

https://www.heihei.com?qrCode=URLENCODE(https://qr.95516.com/00010000/

xxx)

1419561-20200928084838683-1907722064.jpg

总结

聚合收款码统一了用户支付流程，提高商家的收款效率。

另外聚合收款码其实还可以跟商家后台一些 ERP 等软件打通，这样还提高的商家生产效

率。

不得不说，第一个设计出聚合收款码的的产品，真是个鬼才~

聚合收款码，背后原理一点也不难，根据用访问请求的 User-Agent ，以此判断用户当前

扫码使用的客户端类型。

完成支付。