扫码付款时你有没有注意过：同样是”扫一下就能付”，有的二维码扫开直接唤起钱包，有的扫开是一个网页。这中间的分岔有一份 2013 年的提案在管——BIP-73，全称 Use “Accept” header for response type negotiation with Payment Request URLs，2013 年 8 月 27 日立项，作者 Stephen Pair，来自支付服务商 BitPay，状态 Deployed。它解决的是支付协议时代一个非常具体的工程痛点：二维码太长太密，扫不动。
问题：完整链接塞进二维码的代价
支付协议把一条带 r= 请求端点的 bitcoin: 链接印成二维码，URL 越长，二维码点阵密度越高，低分辨率摄像头越难扫；而且通用二维码扫描器根本不认识 bitcoin: 前缀，扫出来只能当一串文本。BIP-73 的解法是反过来：二维码里不装整条支付链接，只装一个短网址端点，钱包去请求这个端点，由服务器按钱包的能力决定回什么。规范明确：这份提案不要求完整实现 BIP-70，钱包可以只走到”拿到一条比特币链接”为止。
规则：Accept 头就是钱包的自报能力
协商靠 HTTP 的 Accept 头完成。钱包扫描后向端点发请求，用 Accept 头声明自己能接收什么：text/uri-list 表示能处理一条 bitcoin: 链接；application/bitcoin-paymentrequest 表示能吃支付协议的收款请求（媒体类型定义见本批专文《收款消息的标签怎么贴：BIP-71 与支付协议 MIME 类型》）。规范特意说明实现不必吃透 Accept 头的全部语义，只需要遵守一个优先序：头里出现 application/bitcoin-paymentrequest，服务器应无条件回支付请求；只出现 text/uri-list，就回一条有效链接；两个都没有，服务器可以回一个 HTML 页面。若返回 uri-list 且列表有多行，取第一条使用，其余忽略。
兜底：扫不出钱包的人也有路走
没人声明能力时回 HTML，是给”非钱包用户”准备的兜底：通用扫描器扫端点、浏览器打开、页面上给出付款链接，点一下照样能把钱付出去。规范还给不支持 BIP-73 的钱包列了两条绕行通道：服务器提供把二维码切换成裸 bitcoin: 链接的选项，或者用户干脆用通用扫描器扫端点网址。今天看，这些通道比协议本身活得更久——收款页给”复制链接”按钮、给”用钱包打开”深链，干的还是同一件事：把内容协商从 HTTP 头搬到页面层。
隐私上的一个暗礁
请求型收款有一个裸地址收款没有的副作用：钱包去端点取账单的那一刻，服务器就知道”有人在这个 IP、这个时间、扫了这张码”。规范对 Accept 协商写得很细，对这条元数据通路却没有约束——静态二维码配动态端点的部署里，商户侧日志天然带上了扫描行为的时间戳。对隐私敏感的用户，选择”直接复制 bitcoin: 裸地址转账”可以把这条观察通道一并关掉；对商户，这层日志同样是资产，只是要承担保管义务。协商机制与隐私成本是同一枚硬币的两面，BIP-73 把便利放在了前面。
用户侧的症状对照
把这套规则翻译成排查手册：扫码直接弹出钱包并预填好收款方信息，说明端点按钱包声明回了链接或请求；扫码弹出的是网页，可能你的钱包扫描器没带 Accept 声明，也可能是通用扫描器，属于规范预设的正常路径；扫码全无反应，先怀疑端点失效或链接过期——请求型收款的前提是服务器持续在线，这一点与裸地址收款根本不同（裸地址链接的语法边界见 bitcoin 链接是什么？比特币 URI 语法与 req 参数规则解读）。还有一条防御线值得记住：端点回来的账单是服务器单方声明，商户名、金额字段的可信度取决于签名与校验质量，历史教训见 BIP70 支付协议兴衰史：比特币收款账单为什么没能标准化。
它今天还有意义吗
支付协议本体在比特币核心里已被移除（见 比特币放弃的支付协议：BIP70 与 Core 0.20 的删除记录），BIP-73 的 Deployed 状态因此更像一块文献界碑：它标记了”用服务器端协商改善扫码体验”这条思路的最早标准化尝试。后来接管这条赛道的是闪电网络的发票体系与各家收单服务的私有方案，但它们面对的问题——码太密、钱包能力不一、兜底给网页——与 2013 年一字不差。读懂 BIP-73，等于拿到一副通用镜片：任何收款二维码扫出不同结果时，你能立刻把差异归位到”能力协商”这一层，而不是怀疑钱包坏了。
风险提示：本文为收款协议机制科普，不构成投资建议；端点服务、协议支持随实现版本变化，商户对接请以当期文档实测为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。