现在的链上付款卡在哪
规范的动机章节把现有体验归为两类：一类是手动转账或扫码，地址、链、币三样全靠自己核对，出错率高；另一类是流程复杂的引导，选币、选链、等地址、再确认，一次简单支付要花四到六次交互。已有的支付链接方案如 ethereum: 网址是单一生态的，且依赖二维码，没法作为连接流程的一部分批量走 WalletConnect 这类通道。对这种缺口的另一种读法可以看《支付链接里到底写了什么？EIP-681 请求的地址、链标识与金额逐项拆》。
一个请求装下全部付法
编号 358 的链无关协议（CAIP-358）定义 JSON-RPC 方法 wallet_pay，核心思想是：商家把「所有我接受的付款方式」一次传全，钱包根据用户账户里实际持有的资产和自己的服务能力，挑一个最优解执行。版本一规定了四个请求字段。version 必须是整数，用来锁定后面字段的取舍规则；orderId 唯一标识订单，长度不得超过 128 个字符，规范要求它不必全球唯一、但建议用 UUIDv4；expiry 是秒级 UNIX 时间戳，超过即视为过期，规范建议至少给三百秒；paymentOptions 是至少一条的选项数组。商户可以用数组顺序表达偏好——JSON-RPC 保证数组有序，但钱包并没有义务照单执行，也可以提供换币或跨链帮助用户凑上商家的首选。
七种转账类型与两种方向
每个支付选项含四个字段：asset 必须写成 CAIP-19 资产标识（自带 CAIP-2 链前缀）；amount 必须是该资产最小单位的十六进制串；recipient 必须是与 asset 所指的链原生格式的收款地址；types 列出这一选项允许的授权方式。版本一的授权方式是一张封闭清单，共七项：native-transfer 与 spl-transfer 这类原生币转账、erc20-transfer 代币直转、erc20-approve 与 spl-approve 批准额度、erc2612-permit 与 erc3009-authorization 两种链下签名授权。规范把前三种归为 PUSH——由付款用户自己发起链上交易；后四种归为 PULL——由收款方或第三方发起链上交易、用户只交出一份签名。方向不同，后果不同：PULL 类在你签名那一刻就把「对方可以在有效期内动你一笔额度」写进了凭据里，核对时间窗比看金额更要紧。
回执、幂等与四个错误码
成功响应回填 payment（实际使用了哪个选项，必须是请求里给过的之一）与 receipt：凭据里带转账类型、哈希或签名、以及 from、to、value 三个要素，签名类类型还会带 nbf、exp 与 nonce。方法对同一 orderId 必须幂等：已成功过的订单再收到请求，钱包必须原样返回原结果而不重复付款；进行中的应当返回原尝试的状态；失败过的可以重试也可以回原错误。钱包应把已完成订单的状态至少保留二十四小时，连接断了应用可以拿同一订单号重发查询。失败错误码有四个：用户拒绝是 8001，账户里没有匹配的资产是 8002，请求过期是 8003，余额不足是 8004；钱包根本不支持这条方法时按 JSON-RPC 惯例回 -32601。
明确不管的事
规范的安全章节写得很克制：wallet_pay 不解决商家欺诈，不赔付货不交货，也不内置争议处理，这些被列为未来工作。隐私章节倒是做了两个设计：请求故意不要求用户提供钱包地址，一来少一个跨站关联标识，二来钱包可以自选从哪个账户付款；同时鼓励钱包在合适场景用隐私协议执行交易，避免购买记录直接暴露公网链上可查。对用户的实际含义是：这类协议把「付得顺」提得很前，而「买了后悔」的保障并不在协议层，收货、争议仍要靠平台规则兜底。
边界：草案状态与兼容策略
该提案 2025 年立项，写作时状态是 Draft（草案）。它的兼容策略是双发：商家同时发一条传统连接请求和一条 wallet_pay，支持的钱包只回应后者走简化流程，不支持的钱包把未知方法当耳旁风、继续走老路径。这类「新旧并行再逐步收口」的手法在连接协议里也出现过，《带编号和不带编号的两种钱包连接：CAIP-316 会话生命周期对照表》里讲过同款思路。落到日常：在支持前你大概率不会遇到它，遇到时先查订单号、再看签名类选项的时间窗，最后到区块浏览器核对到账，可照 转账后多久到账？区块浏览器里怎么看确认数 的确认数口径操作。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。