稳定币支付的授权、扣款和退款有何区别？

稳定币支付产品常把整个流程压缩成一个“Pay”按钮，但后台可能经历创建、授权、捕获、结算、撤销和退款。每个状态对余额占用、商户交付和用户申诉的含义不同，混用会造成重复扣款或提前发货。

用状态机代替成功或失败

Coinbase Payment Acceptance支持authorization、capture、void和refund等标准支付原语。授权表示付款条件或资金可用性得到确认，捕获或扣款才进入实际收款流程。某些产品允许先授权、后按订单金额捕获；另一些产品则直接扣款。接入方必须按所用API的真实模型实现，不能把银行卡经验原样套入链上支付。

建议至少保存created、authorized、captured、settled、voided、refunded与failed，并记录每次状态变更的时间、操作者和上游事件ID。状态只能沿允许的边移动，已退款订单不应再次捕获，已撤销授权也不应继续交付。

状态	用户看到什么	商户能否交付	对账重点
已创建	订单待付款	否	报价与有效期
已授权	资金条件已确认	视风险策略	授权金额与过期时间
已扣款/捕获	收款流程已启动	通常可进入履约	金额、资产、网络
已结算	收款方可核对到账	是	链上与平台账本
已撤销	未完成扣款的授权释放	否	不应再入账
已退款	返还流程已发起或完成	已交付则另行处理	退款ID与到账证据

金额为什么必须使用字符串

官方流程先创建支付会话并由买方授权，商户在履约后执行capture，之后才进入结算。支付API常要求金额使用十进制字符串，目的是避免二进制浮点把0.1等数值表示成近似值。应用应在边界层验证币种精度、最小单位和小数位，不在浏览器里先做浮点运算再提交。

账本同时保存原始字符串、资产标识、网络、精度和折算口径。若订单以法币计价、用稳定币支付，还要记录报价来源和锁价时间。退款时不能只拿今天汇率倒推稳定币数量，否则用户收到的资产单位可能与原扣款不一致。

撤销和退款不是同一个动作

void用于未捕获支付的撤销，而refund面向已经完成的支付；两者在会计记录和业务证据上不能合并。撤销通常针对尚未完成捕获的授权，目的是释放或取消；退款发生在资金已扣取之后，需要形成新的返还流程。两者在API、用户等待时间和会计处理上不同。

客服文案也要区分：“授权已撤销”表示不会继续完成这次扣款；“退款处理中”表示返还已经发起但可能尚未到账。若链上返还是一笔新交易，应向用户提供新哈希、网络和预计确认条件，而不是让用户只查看原付款交易。

幂等键保护哪一步

支付API建议使用字符串表达金额并用幂等键安全重试，避免浮点误差或重复创建支付。创建、扣款、撤销和退款都可能因网络超时被重试。幂等键要与业务动作绑定，同一订单的捕获重试复用一个键，而退款与捕获使用不同动作键。服务端应返回原结果，而不是再次执行资金动作。

幂等不能替代状态查询。客户端收到超时时，应先查询订单和支付对象，再决定是否重试；后台收到重复Webhook时，应按事件ID去重并核对状态版本。若两个系统并发修改同一订单，需要乐观锁或明确的状态机版本控制。

对账要有三条记录

第一条是业务订单，回答买了什么、是否交付；第二条是支付服务记录，回答授权、捕获与退款状态；第三条是链上或托管账本，回答资金移动。三条记录通过订单ID、支付ID和交易哈希连接，但不能相互替代。

日终对账应列出金额不一致、状态停留过久、链上成功但订单失败、订单退款但链上未返还等异常桶。每个异常桶有负责人、补偿方式和最长处理时限。不能用人工改成“成功”来消除报表差异。

一次完整的异常演练

模拟授权成功后捕获超时：前端显示处理中；后台查询上游支付对象；若已捕获，则补写订单状态并去重Webhook；若明确未捕获，再安全重试；若状态未知，进入人工队列。整个过程不要求用户重新签名，除非旧授权确实失效且页面明确说明。

支付接口或政策会变化，产品上线前应以当前官方API定义为准。稳定币仍有发行人、储备、赎回、合约和监管风险，支付状态正确不等于资产本身没有风险。

支付状态要能同时被用户和账本理解

前端用词、API状态和会计分录应指向同一件事。若系统只留下一个“成功”布尔值，授权、实际扣款、撤销和退款就会在异常处理中彼此冲突。