Request Finance 已付但未到账：核对发票ID、status与结算
链小知 · 进阶 · 核验 · 依官方文档整理
从同一invoice/request读取状态，区分accepted、declaredPaid、paid与银行最终入账。
开始前准备
- 准备本人有权限查看的invoiceId/requestId、币种/网络或银行支付路径、付款hash与业务订单；不共享带访问token的发票链接。
- 适用Request Finance REST invoices文档与2026-05-07结算帮助；Crypto-to-Crypto和Crypto-to-Fiat状态分别解释。
- 全部API需账户访问权限；用本人现有API/OAuth会话读取，不创建、确认、标记已付或支付发票。读取无链上gas，实际付款/服务费按方案。
1. 先定位发票而不是付款截图
保存invoiceId与链上requestId，官方推荐用requestId读取；只有付款截图、发票显示编号或hash时，先在本人已有账户找到对应发票。
已有API权限可GET https://api.request.finance/invoices/[id]。需要列表定位时用search筛选hash/编号，并按take/skip翻页；列表第一页未找到不能判断发票不存在。
检查结果：定位同一业务发票与角色，不创建替代发票。
2. 核对权限与付款路径
请求使用当前官方认证方案，文档示例要求JSON头和Authorization:本人API_KEY；凭据只在本人环境使用。失败先确认账户/组织权限与ID，不以认证失败判断发票未付。
读取paymentOptions中的币种、网络、paymentAddress或实际银行路径，核对type与角色。相同稳定币名不代表相同支付网络。
检查结果：发票属于正确业务、角色和付款路径。
3. 按业务类型解释status
accepted只是买方接受；open是请求已创建但尚未付款。declaredPaid对外部付款可能只是买方声明，仍需卖方确认；Crypto-to-Fiat则表示加密资金到达银行合作方。
paid对Crypto-to-Crypto表示买方已付，但可被标回未付；对Crypto-to-Fiat表示合作方已发送银行付款，不证明收款人账户已经显示金额。保存实际status与读取时间。
检查结果：status按Crypto-to-Crypto/Fiat语义解释，未混用。
4. 核对付款记录与终止状态
将trackedTransactions、发票事件和本人付款hash与当前发票关联；只有链上hash还不能证明它付给了此发票指定地址、资产和金额。数据不足时列明差项。
pending需等异步请求创建结果；draft未变成可付链上请求。canceled/rejected是终止状态，不继续当作等待付款发票，也不擅自修改状态来解决核账差异。
检查结果：发票状态和相关付款证据能对应，或明确未知。
5. Crypto-to-Fiat另核银行入账
status=paid后按实际银行网络、币种与业务日查看收款记录。官方说明常见到账窗口取决于SEPA、ACH/Wire、SWIFT等，周末与路径不能按链上确认分钟数计算。
保存发票ID、付款时间、发送网络/银行路径、状态与收款记录；超过当前帮助适用窗口由本人联系官方支持。不要重复付款验证，也不把手续费差额未经核对归为缺款。
检查结果：链上付款、合作方发送、银行入账分别有证据。
怎样确认完成
- 形成同一发票状态、支付路径、付款证据与最终收款的对照。
- 依据官方文档整理，真实账户/API返回与资金操作尚待实际验证。
常见错误与边界
- declaredPaid和accepted不是到账证明。
- 带token的invoiceLinks可能有访问含义，不放公共工单。