poxiaoxi博客线下门店经常会遇到一个很实际的问题：柜台上既要放微信收款码，又要放支付宝收款码。消费者付款时需要先判断自己使用哪个 App，再找到对应二维码。于是就出现了所谓的“微信支付宝二合一收款码”或“聚合收款码”——桌面上只放一张二维码，微信可以扫，支付宝也可以扫。
从表面看，它像是把两个二维码“合成”了一张。但从二维码本身的工作方式来看，这种理解并不准确。真正被整合的通常不是两张二维码图片，而是二维码后面的访问入口、支付路由或者商户收单系统。
二维码本身存的是什么
二维码本质上是一种信息编码方式。扫描二维码以后，扫码软件会还原其中保存的一段数据，这段数据可能是普通文字、网址、应用协议地址，也可能是支付平台生成的特定支付参数。
例如，商户接入微信支付 Native 支付时，商户后台需要先向微信支付发起下单请求，微信支付返回用于支付的 code_url，商户再把这个地址生成二维码。消费者用微信扫描后，微信客户端根据其中的信息进入后续支付流程。
支付宝的订单码支付也采用类似思路。商户创建订单后获得对应二维码信息，再由用户使用支付宝扫描并完成付款。
因此，二维码图片只是信息的视觉载体。真正决定“扫完以后去哪儿”的，是二维码里面保存的数据以及扫码 App 对这些数据的处理方式。
两种“合并收款码”并不相同
日常所说的微信支付宝二合一收款码，实际上可能对应完全不同的技术方案。比较常见的可以分成两类。
第一类是二维码中转。它不直接把微信支付地址和支付宝支付地址同时写进二维码，而是生成一个新的中间地址。微信和支付宝扫描的其实都是这个统一入口，然后服务器再判断扫码环境，把用户引导到对应的付款流程。
第二类则是真正的聚合支付。商户接入支付服务商或者自己的支付系统，一张二维码对应的是统一商户、门店、订单等信息。支付系统在后台分别对接微信支付、支付宝等支付渠道，并统一处理订单、通知和对账。
两种方式看起来都是“一张码”，但后台结构、资金处理方式以及适合的使用场景差别很大。
简单合并的技术原理
一些所谓的“微信支付宝收款码合并工具”，使用的思路其实比较容易理解。
假设商家原来已经有一个微信收款入口和一个支付宝收款入口，系统另外生成一个统一地址，例如：
https://example.com/pay/abc123
然后把这个地址生成新的二维码。消费者扫到的就不再是原来的微信码或者支付宝码，而是这个网址。
访问服务器以后，系统可以根据当前扫码环境进行判断。例如在某些实现中，可以根据浏览器环境、客户端标识或者已经建立的支付场景判断用户来自微信还是支付宝。
统一二维码 ↓ 中转地址 ↓ 识别扫码环境 ↙ ↘ 微信 支付宝 ↓ ↓ 微信支付 支付宝支付
所以这里的“合并”更准确地说是把两个入口放到了一个路由系统后面。
二维码里并不是同时塞进两张原始收款码，真正保存的通常只是一个统一入口。
商户聚合支付如何工作
如果是门店使用的正规聚合支付系统，结构通常会更完整。
消费者扫描二维码后，首先进入商户或者支付服务商的支付系统。系统建立订单，再根据消费者选择或者当前支付环境调用对应支付渠道。
以微信支付为例，商户后台可以调用微信支付接口创建支付交易，并获得相应支付参数；支付宝也提供当面付、扫码支付等面向线下收款场景的接口。
于是一个聚合支付系统实际上可能同时维护多套支付通道：
消费者 ↓ 统一收款二维码 ↓ 商户 / 支付服务商 ↓ 支付路由系统 ┌─────┴─────┐ ↓ ↓ 微信支付 支付宝 ↓ ↓ 支付结果 支付结果 └─────┬─────┘ ↓ 商户订单系统
对消费者来说，只看到了一张二维码；但对于后台来说，微信订单和支付宝订单仍然需要按照各自支付平台的接口、交易状态和通知机制处理。
所以“一码收款”并不意味着微信支付和支付宝在底层变成了同一个支付系统，而是上层系统把不同支付渠道统一到了同一个收银入口。
扫码之后经历哪些步骤
如果按照完整的聚合支付思路，一次扫码付款大致可以拆成几个环节。
消费者扫描商户展示的统一二维码。
二维码中的商户或订单信息被客户端解析。
请求进入商户或者聚合支付服务系统。
系统确定消费者使用的支付渠道。
后台通过相应支付接口创建交易。
消费者在微信或支付宝中确认付款。
支付平台完成交易并返回支付结果。
商户后台接收支付通知并更新订单状态。
收银系统显示付款成功，并进入后续对账流程。
其中真正复杂的地方并不是“生成二维码”，而是订单创建、支付渠道接入、异步通知、订单查询、退款、异常处理和财务对账。
静态码和动态码也有区别
看到一张长期贴在柜台上的二维码，并不代表每一次支付对应的二维码内容都必须重新变化。
一种做法是使用固定入口。二维码长期不变，用户扫码以后再进入系统创建具体订单。这种形式适合桌贴、收银台立牌等场景。
另一种则是根据订单动态生成二维码。比如收银系统产生一笔 68 元订单，后台先创建支付订单，再生成与本次交易对应的二维码。订单结束以后，这个二维码就不再承担下一笔交易。
动态订单码更容易把金额、订单号和商品交易对应起来，因此在完整的商业收银系统中更容易实现自动确认付款、退款和财务对账。
个人收款码合并要区别看待
网上还有一种常见工具：上传自己的微信收款码和支付宝收款码，几秒钟生成一个新的“二合一收款码”。这种工具与商户聚合支付并不是同一个概念。
有些工具只是生成一个中间页面，根据扫描环境展示或者跳转到对应收款入口，并没有真正接入微信支付或支付宝的商户支付接口。
这类方案看起来简单，但实际使用时需要考虑几个问题。
中转服务器停止服务后，二维码可能随之失效。
支付平台对普通网页、二维码跳转以及支付场景有自己的处理规则，兼容性可能发生变化。
把自己的收款二维码上传给未知第三方，需要注意二维码被替换、页面被修改等风险。
如果用于长期经营收款，还需要区分个人收款场景和商户经营收款场景，并遵循对应支付平台的规则。
因此，如果只是理解“一张码为什么能跳到两个收款入口”，中转页面已经足以说明技术原理；如果是门店长期经营使用，则不能只看二维码能不能扫，还要关注商户签约、交易记录、退款、对账和资金安全。
聚合支付的价值不只是少放一张码
对于小摊位来说，一张二维码代替两张二维码，最直观的价值可能只是桌面更加简洁。
但对有收银系统的门店而言，真正有价值的是后台统一。
如果微信、支付宝分别独立收款，收银员可能需要分别查看两个平台的交易记录。接入聚合支付系统以后，订单系统可以按照统一订单号记录不同渠道的付款结果，从而进一步处理门店流水、退款和对账。
换句话说，二维码只是用户看到的入口，后面的支付系统才是聚合支付真正需要解决的问题。
精彩评论