加密货币账单全流程：从订单号到链上确认

加密货币账单把订单和一笔受监控的链上付款连起来。账单把商户订单号绑定到预期金额、有效期、合法的资产与网络选择、支付状态和最终的交易记录上。它是每种 Paymos 收款界面 背后的交易记录。

光给一个钱包地址做不到这些：它认不出订单，决定不了付款何时算数，也告诉不了商户系统何时履约安全。账单补上了这层商业上下文。更宏观的模型见加密货币支付原理。

一张加密货币账单需要哪些信息？

一张生产可用的账单回答三个问题：客户应付多少、能往哪里付、商户怎么把转账对上订单。至少要存：商户订单号、应收金额、计价币种、有效期、所选资产与网络、收款地址、账单状态和链上交易引用。

在给客户看的每个标签里，资产和网络都要成对出现。只写 USDT 不完整——Tron 上的 USDT 和 Ethereum 上的 USDT 是两种不同的链上资产。付款说明里还要有二维码或可复制的地址、精确的代币数量和实时状态。商户记录里同时保留自己的订单号和处理商的账单号，客服和对账才能从任一端追溯。

创建账单怎么防重复？

创建账单必须在业务订单层面幂等。一次超时会让商户不确定第一次请求是否成功，不带稳定标识重试就可能为同一订单开出两张可付账单。

Paymos 用调用方提供的 external_order_id 解决这件事：重复使用同一外部订单号返回已有账单。Paymos 创建账单不用 Idempotency-Key 头，所以集成方应在第一次 API 调用之前就生成并持久化订单号。

把返回的 Paymos 账单号和原订单存在一起。响应丢了，就用同一个 external_order_id 重发请求，然后基于已有账单继续。这比每次传输出错都生成新标识安全。

客户怎么拿到付款要素？

钱包转出之前，客户需要一条无歧义的付款路由。Paymos 可以通过托管收银台、内嵌 iframe、收款链接、Low-Code SDK、CMS 插件，或基于 REST API 的自建界面呈现。路由要显示所选资产、网络、金额、地址、二维码和当前状态。

托管收银台负责支付界面，商户保留订单和履约逻辑。CMS 插件把同一套账单模型接到受支持的电商或计费平台上。REST API 适合需要自定义界面的团队，但也把校验、错误处理、签名请求、状态展示和对账的责任交给了他们。选能满足产品体验要求的最简界面。

Paymos 账单的完整生命周期是什么？

接入界面会变，控制闭环不变：

1. 用稳定的 external_order_id 创建账单
2. 通过收银台、链接、插件、组件或自建界面给出可用的资产与网络路由
3. 买家钱包发出付款并承担发起方的网络费
4. 等待 Paymos 按该网络和金额应用确认策略
5. 按项目的少付容差处理实际到账金额
6. 先验签并持久化记录 webhook，再执行履约
7. 对账：订单号、Paymos 账单号、到账金额和链上交易引用

这条顺序标明了防重复、终局性、少付和履约控制在每种接入界面上的位置。具体请求格式取决于所选界面，走自定义路径的团队可配合 REST API 收款指南。

检测到付款后什么时候履约才安全？

检测到不等于终局。处理商可能在网络给出足够可信度之前就观察到一笔交易。账单只有在适用的确认策略完成后，才应进入可履约状态。

Paymos 的确认策略按网络和支付金额制定：小额付款所需确认更少，大额付款等待更强的阈值。不存在对每张账单都成立的统一确认时长，网络状况也会改变实际耗时。

只依据最终的已支付状态履约。钱包截图、客户给的交易哈希、早期的「已看到」事件都不能作为依据。所需深度为何变化，见区块链确认指南。

少付容差怎么运作？

少付按项目级百分比处理，不靠客服临时判断。容差从 0% 到 2%，每档 0.1%，新项目开出来是 0.1%：够抹掉一条尾数，成不了折扣。设成 0% 就是严格匹配，付款要等于账单金额或更多。到账金额落在配置的容差内，账单完成，商户按实付金额结算，差额没人补。

单次付款账单低于阈值则保持少付状态；允许多次付款的账单可以保持打开，等付方补足。集成应展示这种状态，而不是悄悄把订单标成已付清。

容差按订单经济学来设。小比例可以吸收钱包舍入、不产生人工工作量；容差放得太宽，等于把定价错误变成每张账单都接受的折扣。

签名账单 webhook 该怎么处理？

webhook 把账单状态送进商户系统。Paymos 用 HMAC-SHA256 签名，放在 X-Webhook-Signature 头里，格式为 t={timestamp},v1={hmac_hex}。接收方应先用定时安全比较校验时间戳和签名，再把事件当作可信数据解析。

投递会重试，处理逻辑必须幂等。一个 Paymos 投递周期共 11 次尝试——首次加十次重试——跨约 16 小时。投递失败或无法送达的事件可手动重放。

事件持久化记录之后再返回成功，然后基于这条记录执行履约。下游工作失败就在内部重试，不要让 webhook 发送方重复一个已经成功落库的事件。

X-Webhook-Signature: t=1785326400,v1=2b4f...
Content-Type: application/json

对账要存什么？

对账要形成一条完整链路：商业订单、处理商记录、链上交易。存外部订单号、Paymos 账单号、应收与实收金额、资产、网络、交易引用、最终状态和相关时间戳，以及用于防重复执行的商户自定义处理键。

对账以处理商状态为准，不以客户给的交易哈希为准。一笔转账可能用错资产、走错网络、发错地址或金额不足，但在区块浏览器里看起来仍像那么回事。账单状态才是按付款请求对转账做的判定。

客服要能通过三个标识找到同一条记录：订单号、账单号、交易引用都能命中。这减少退款错误，也在客户对履约提出异议时给出可辩护的审计轨迹。

该选哪种账单接入方式？

偶尔手动开单用收款链接，适合销售或客服侧的开票。网站需要完整付款页但不想自己处理钱包交互，用托管收银台或内嵌流程。店铺跑在受支持平台上，用官方 CMS 插件。

真正自定义的流程才选 REST API。Paymos 的沙盒和正式环境凭证分开、API 面相同，团队可以在动真金白银之前测账单结果和 webhook 处理。收款和转出凭证也是分开的。

无论走哪条路，控制闭环不变：用稳定的外部订单号创建、给出精确付款要素、等待最终已支付状态、验签 webhook、对账之后再履约。