01｜先画地图：Web3 支付系统到底由哪些部分组成
这一篇要解决的问题
这一篇先建立 Web3 支付系统的总地图。重点不是评价 Web3 支付是否成熟，而是把一次付款从用户发起、链上确认、商户识别订单、资金结算、风控合规到财务入账的路径拆开。
正文
1. Web3 支付系统处理的基本问题
支付系统的核心任务是让一方把价值交给另一方，并让双方都能确认这件事已经发生。
在传统支付里，用户刷卡、扫码或转账，背后有银行、卡组织、支付机构、清算网络、商户收单机构共同完成记账和结算。
在 Web3 支付里，价值转移通常发生在链上。用户用钱包签名，把某种链上资产转给商户地址、支付合约或支付服务商控制的地址。链负责记录资产转移，支付系统负责把这笔链上交易解释成一笔商业订单。
所以 Web3 支付系统至少要同时处理两套账：
| 账本 | 记录什么 | 谁关心 |
|---|---|---|
| 链上账本 | 某个地址向另一个地址转了多少代币 | 用户、商户、钱包、链上浏览器、支付网关 |
| 业务账本 | 哪个用户为哪个订单支付了多少钱，是否到账，是否可发货 | 商户、支付服务商、财务、客服、风控 |
链上转账本身只说明“资产从 A 地址到了 B 地址”。商业支付还需要回答：这是谁付的，付的是哪笔订单，金额是否足够，币种是否正确，汇率按哪一刻算，是否可退款，商户最后拿到什么资产。
2. 一次 Web3 支付的基本链路
可以先看一条最简化的链路。
| 步骤 | 发生什么 | 关键问题 |
|---|---|---|
| 1 | 商户创建订单 | 金额、币种、过期时间、收款地址如何生成 |
| 2 | 用户连接钱包或扫码 | 用户用哪个钱包、哪条链、哪种资产支付 |
| 3 | 用户签名并广播交易 | 钱包提示是否清楚，Gas 谁付，交易是否可能失败 |
| 4 | 链上确认交易 | 需要几个确认，是否存在重组或延迟 |
| 5 | 支付系统识别到账 | 如何把链上交易匹配到订单 |
| 6 | 商户确认履约 | 发货、开通服务、发票、通知用户 |
| 7 | 资金结算 | 商户保留加密资产，还是换成稳定币或法币 |
| 8 | 对账和风控 | 是否有高风险地址、退款、争议、合规记录 |
这条链路里，链只负责其中一部分。支付产品的价值经常体现在链外部分：订单管理、地址分配、交易监听、汇率换算、商户后台、结算报表、合规风控、客服处理。
3. Web3 支付系统的 7 层结构
可以把 Web3 支付系统拆成 7 层。
| 层次 | 解决的问题 | 常见组件 |
|---|---|---|
| 用户入口层 | 用户如何发起付款 | 钱包、二维码、Pay Button、WalletConnect、浏览器插件 |
| 账户和签名层 | 谁在授权这笔支付 | 私钥、助记词、地址、智能合约钱包、多签、账户抽象 |
| 资产层 | 用什么支付 | 稳定币、原生代币、平台币、法币兑换入口 |
| 网络层 | 交易在哪条链上发生 | Ethereum、Solana、Polygon、Base、Arbitrum、Optimism、Tron 等 |
| 支付处理层 | 如何把链上交易变成订单状态 | 支付网关、地址池、合约收款、交易监听、回调 Webhook |
| 结算层 | 商户最后拿到什么 | 原币结算、稳定币结算、法币结算、自动换汇、提现 |
| 风控合规层 | 哪些交易可以接受 | KYC、AML、制裁筛查、地址风险评分、地区限制、限额 |
理解 Web3 支付时，要先定位一个产品主要在做哪一层。
钱包产品多在用户入口层和账户签名层。稳定币发行方主要在资产层。公链和 Layer 2 主要在网络层。支付网关多在支付处理层和商户结算层。链上风控公司主要在风控合规层。
4. 钱包：Web3 支付里的用户入口
在 Web3 支付里，钱包承担了传统支付中一部分“账户 + 授权工具”的角色。
钱包至少做三件事：
- 管理私钥或账户权限。
- 展示用户拥有的资产。
- 让用户对交易进行签名。
用户点击支付按钮后，钱包会弹出交易信息。用户确认签名，交易才会广播到链上。
这里的体验难点很明显：
| 难点 | 表现 |
|---|---|
| 地址难读 | 用户很难判断收款地址是否正确 |
| 网络选择复杂 | 同一种资产可能存在于多条链上 |
| Gas 概念陌生 | 用户需要理解手续费和原生代币 |
| 签名风险 | 恶意网站可能诱导用户签危险授权 |
| 交易不可逆 | 转错地址或付错链路，追回困难 |
因此，很多 Web3 支付产品会尝试降低钱包复杂度，比如托管钱包、社交登录钱包、账户抽象钱包、免 Gas 支付、代付 Gas、一次性收款地址、支付链接等。
5. 稳定币：Web3 支付里最常见的计价资产
支付需要稳定的计价单位。BTC、ETH 等资产价格波动较大，用来做日常支付时，商户和用户都要承担价格波动。
稳定币因此成为 Web3 支付里最常见的资产层组件。
| 稳定币类型 | 机制 | 支付中的特点 |
|---|---|---|
| 法币储备型 | 发行方持有美元、国债等储备 | 最接近美元支付体验，依赖发行方和托管体系 |
| 加密抵押型 | 用链上资产超额抵押生成 | 更链上原生，但抵押资产波动会影响稳定性 |
| 算法或混合型 | 依靠机制设计维持锚定 | 风险更高，需要重点看极端情况下能否维持锚定 |
商户接受稳定币时，仍然要处理几个问题：
- 接受哪种稳定币。
- 接受哪条链上的稳定币。
- 汇率按下单时、支付时，还是确认到账时计算。
- 稳定币是否可以被冻结、拉黑或受发行方规则影响。
- 商户最后保留稳定币，还是换成银行账户里的法币。
稳定币让 Web3 支付更接近传统支付，但它也把银行、托管、发行方、监管和赎回能力重新带回系统。
6. 网络层：链决定成本、速度和最终性
Web3 支付发生在哪条链上，会直接影响用户体验。
| 网络特征 | 对支付的影响 |
|---|---|
| 手续费 | 小额支付能否成立，用户是否愿意支付 Gas |
| 确认速度 | 商户多久敢确认订单 |
| 最终性 | 交易是否可能被回滚或重组 |
| 生态支持 | 钱包、交易所、稳定币、开发工具是否完善 |
| 安全性 | 链本身是否稳定，是否容易拥堵或停机 |
| 合规接受度 | 商户、支付服务商和监管机构是否容易接受 |
不同链适合不同支付场景。
| 场景 | 更重视什么 |
|---|---|
| 小额高频支付 | 低手续费、快确认、好钱包体验 |
| 跨境 B2B 结算 | 稳定币深度、合规、清晰对账 |
| 链上应用内支付 | 与应用所在链的组合性和钱包兼容 |
| 大额资金结算 | 安全性、最终性、托管和风控 |
网络层的选择不是纯技术选择。它会影响用户需要持有什么资产、商户怎么结算、支付服务商怎么风控、客服怎么处理失败交易。
7. 支付网关：把链上交易翻译成商户能用的订单状态
商户通常不想直接处理所有链上细节。支付网关的作用，是把复杂的链上交易流程包装成商户熟悉的接口。
一个 Web3 支付网关通常会提供：
| 能力 | 作用 |
|---|---|
| 创建支付订单 | 生成金额、币种、地址、二维码和过期时间 |
| 监听链上交易 | 发现用户是否支付，确认金额和币种 |
| 订单状态回调 | 通过 Webhook 通知商户已支付、失败、过期 |
| 汇率换算 | 把美元、人民币或其他计价单位换算成代币数量 |
| 结算管理 | 帮商户保留币、换稳定币或提现法币 |
| 对账报表 | 让财务知道每笔订单对应哪笔链上交易 |
| 风控筛查 | 识别高风险地址、制裁地址、混币器相关资金 |
支付网关的核心难点，是链上世界和商户业务世界之间的映射。
链上可能发生部分支付、多付、少付、超时后到账、不同链转错、用户重复支付、交易卡住、Gas 不够、代币合约异常。商户系统需要一个清晰的订单状态机来处理这些情况。
8. 商户最关心的不是“链”，而是收款体验
对商户来说，Web3 支付要回答的实际问题通常是：
| 商户问题 | 系统需要提供的能力 |
|---|---|
| 我能不能稳定收到钱 | 地址生成、交易监听、确认规则、异常处理 |
| 我最后拿到什么资产 | 结算币种、换汇、提现、资金托管 |
| 财务怎么入账 | 订单号、交易哈希、发票、报表、税务记录 |
| 客服怎么处理争议 | 退款、少付、多付、付款超时、转错链 |
| 风险怎么控制 | 黑名单、地址风险、限额、地区限制、可疑交易报告 |
| 技术接入成本多高 | API、SDK、Webhook、插件、后台管理 |
如果一个 Web3 支付产品只解决“能在链上转账”，它离商户支付系统还有距离。商户需要的是一套可以运营、对账、退款、合规和客服处理的完整流程。
9. Web3 支付和传统支付的关键差异
可以用一张表看差异。
| 维度 | 传统支付 | Web3 支付 |
|---|---|---|
| 账户 | 银行账户、支付账户、卡账户 | 钱包地址、合约账户、托管账户 |
| 授权 | 密码、短信、银行卡网络、支付机构验证 | 私钥签名、钱包确认、合约权限 |
| 清算 | 银行和清算网络完成 | 链上交易确认，外加服务商内部账务 |
| 可逆性 | 可以退款、拒付、争议处理 | 链上转账通常不可逆，退款需新交易 |
| 资产 | 法币为主 | 稳定币、原生代币、链上资产 |
| 风控 | 身份、银行卡、设备、交易行为 | 地址风险、链上路径、身份和地区限制 |
| 用户体验 | 用户熟悉，费用隐藏 | 钱包、Gas、链选择、签名提示更复杂 |
这些差异决定了 Web3 支付的产品设计不能只照搬传统支付，也不能只依赖链上转账。它需要同时理解支付业务和链上资产系统。
10. 先用一张检查表判断 Web3 支付产品
遇到一个 Web3 支付系统，可以先用这张表判断它的边界。
| 检查项 | 要看的问题 |
|---|---|
| 服务对象 | 面向个人转账、商户收款、跨境结算、链上应用，还是企业资金管理 |
| 支持资产 | 支持哪些稳定币、原生币和法币出入金 |
| 支持网络 | 支持哪些公链和 Layer 2，手续费和确认速度如何 |
| 钱包体验 | 用户是否需要自托管钱包，是否支持扫码、支付链接、免 Gas |
| 商户接入 | 是否有 API、SDK、插件、Webhook 和后台 |
| 订单处理 | 如何处理少付、多付、超时、重复支付、转错链 |
| 结算方式 | 商户拿币、拿稳定币，还是拿银行账户里的法币 |
| 风控合规 | 是否做地址筛查、KYC、AML、地区限制和报表 |
| 财务对账 | 是否能把订单、交易哈希、费用、汇率和结算记录对应起来 |
| 失败处理 | 交易失败、链拥堵、钱包报错、退款争议如何处理 |
这张表可以帮助我们把“Web3 支付”从一个大词拆成具体系统能力。
小结
- Web3 支付系统同时处理链上账本和业务账本，链上转账需要被映射成商户可理解的订单状态。
- 一次完整支付包括订单创建、钱包签名、链上确认、交易识别、商户履约、资金结算、对账和风控。
- Web3 支付可以拆成用户入口、账户签名、资产、网络、支付处理、结算、风控合规 7 层。
- 稳定币、钱包、公链和支付网关分别解决不同层次的问题，不能混成一个概念。
- 判断一个 Web3 支付产品，要看它服务谁、支持什么资产和网络、如何结算、如何对账、如何处理异常和合规。
下一篇预告
下一篇进入账户层：钱包、地址和签名。我们会拆清楚 Web3 支付里的“账户”到底是什么，为什么私钥签名能授权付款，托管钱包、自托管钱包、多签钱包和账户抽象钱包分别解决什么问题。