实时支付清算是什么?清算与结算的区别、QRPH/InstaPay 角色分工解析(2026)

我们团队在马尼拉给几十家中国出海商户做支付对接,最常被问到的一句话是:"你们后台显示交易成功,为什么我们财务说钱还没有到账?"这个问题背后,其实是两个完全不同的技术环节被混在了一起说——清算(clearing)和结算(settlement)。很多商户技术负责人习惯把"回调状态"直接当成"钱已经在账上",真出了对账分歧才发现两者根本不是一回事。这篇文章不讲"多久到账"(这个话题我们在别的文章里已经拆得很细),而是把清算这个环节单独摘出来,讲清楚它在 QRPH、InstaPay 这些通道里到底做了什么、由谁负责、商户在对接时该盯住哪些字段。

实时支付清算是什么:先把一个容易被搞混的概念摆清楚

在支付清算体系里,"清算"指的是交易指令在参与机构之间被核对、验证、打包处理的过程——发起行把这笔转账的指令送出去,清算机构核对收款账户信息是否有效、金额和字段是否匹配、这笔交易该计入哪一方的应收应付,然后生成用于后续资金调拨的清算记录。清算解决的是"这笔交易的信息对不对、该怎么记账",而不是"钱有没有真正转移"。资金在机构之间完成不可撤销的最终转移,是结算(settlement)要做的事。所谓实时支付清算,说的是这个信息核对与处理的过程以接近实时的速度完成,而不是资金到账的速度。这个区分看起来像文字游戏,但对商户技术团队的对账逻辑、异常处理逻辑影响很大——把清算完成当成结算完成,对账脚本在交易量上来之后很容易出现两边对不上的假象。

清算与结算:技术上是两回事

把两者放进同一张表看会更直观。清算发生在交易指令层面,参与方是清算机构、发起行、收款行;结算发生在资金层面,参与方是负责最终划转的结算系统和商业银行的结算账户。商户系统能感知到的,通常是清算层面的确认——也就是我们常说的"回调成功"——而结算层面的资金划转,对商户来说是看不见的银行间行为。

QRPH 里谁负责清算、谁负责结算

QRPH 是菲律宾推动的二维码互通标准,它本身不是一套独立的清算体系,而是把不同钱包、不同银行的收款码统一成一种扫码方式,底层的资金指令仍然要走既有的清算和结算轨道。一笔 QRPH 交易发起后,自动清算机构负责核对付款方与收款方的账户信息、比对交易参考号、确认这笔交易该计入哪个参与机构的头寸,这个环节由清算机构完成。等清算记录生成之后,真正的资金转移才通过结算系统在参与银行、钱包运营方之间完成最终划转。也就是说,商户扫码收款背后,至少经过"标准转换—清算核对—结算划转"三层,而不是一步到位。

我们是 BSP 持牌的 OPS(运营支付系统)与 EMI(电子货币机构)双牌照机构,这意味着我们接入的每一条通道都必须遵守监管对清算参与方的资质要求,而不是绕开清算机构直接"模拟"一个到账状态给商户看。

这一点在筛选服务商时很关键:一些非持牌的第四方机构会用"自己先垫付、再和上游轧账"的方式,把清算和结算之间的时间差自己吃掉,商户看到的回调确实很快,但这笔钱有没有真正完成机构间结算,商户完全无法验证。持牌机构因为要接受清算参与方的审计,清算记录和结算记录必须是可追溯、可核对的。

InstaPay 与 PesoNet:清算节奏不同,结算方式也不同

把 QRPH 常用的两条底层轨道拿出来对比会更清楚。InstaPay 走的是逐笔清算模式——每一笔交易发起后,发起行和接收行之间的指令核对是单独进行的;PesoNet 走的是批量窗口清算——交易指令按照约定的批次时间点统一提交给清算机构处理。这两种清算节奏,直接决定了后面结算发生的方式:逐笔清算对应的通常是多边净额结算,批量清算对应的是定时批量结算。想了解这两条通道在限额、场景上的具体差异,可以看我们另一篇InstaPay 与 PesoNet 清算详解,这里只讲清算和结算这一层的架构差异。

想看清算参与机构名单和各参与方接入路径的,可以参考QRPH participants 参与机构名单这篇,里面列了目前接入清算体系的银行和钱包。

清算环节出问题,商户侧会看到什么

清算和结算是两个独立的失败域,商户技术团队最容易踩的坑,是把两种异常混在一起处理。清算层面的异常,通常表现为交易指令被清算机构拒绝——账户信息校验不通过、交易参考号重复、字段格式不符合规范,这类异常一般会有明确的错误码,商户系统应该在收到回调的第一时间区分"清算失败"和"清算通过但结算尚未完成"这两种状态,而不是用一个笼统的成功/失败字段去概括。结算层面的问题,更多体现为商户对账系统发现清算记录和实际到账记录之间存在差异,这种情况通常不代表交易异常,而是两个环节本身处于不同的处理节奏里。我们在D0 结算原理与商户现金流这篇里专门拆过资金到账节奏的问题,这里不重复展开,只强调一点:对账逻辑设计时,应该以清算参考号作为主键去匹配,而不是用金额加时间窗口去猜,后者在交易量上来之后很容易出现误匹配。

从商户 API 视角看清算相关字段

做过对接的技术同学应该都注意到,支付网关返回的响应里,除了金额、订单号这些业务字段,通常还会带一个清算参考号(有的通道叫 trace number,有的叫 clearing reference)。这个字段才是跨机构对账时真正有意义的凭证,建议商户系统把它作为独立字段落库,而不是只存自己生成的订单号。下面是一个查询交易清算状态的请求示例:

curl -X POST https://apix.smartpayph.com/api/query \
  -H "Content-Type: application/json" \
  -d '{
    "merid": "M10086",
    "tno": "ORDER20260929001",
    "sign": "9f1c...(HMAC-SHA256签名)"
  }'

返回结果里,除了订单状态字段,还会带清算层面的关键信息,比如清算参考号、发起行代码、当前所处的清算阶段。商户系统在做异步回调验签和落库时,建议把这几个字段都记录下来,后续遇到对账分歧,直接拿清算参考号去跟清算机构或结算方核对,比重新翻交易流水快得多。下面是一段校验回调签名并提取清算参考号的示例:

const crypto = require('crypto');

function verifyCallback(payload, sign, apiKey) {
  const raw = Object.keys(payload)
    .filter(k => k !== 'sign')
    .sort()
    .map(k => `${k}=${payload[k]}`)
    .join('&') + `&key=${apiKey}`;
  const calc = crypto.createHash('md5').update(raw, 'utf8').digest('hex').toUpperCase();
  if (calc !== sign) throw new Error('签名校验失败,拒绝写入清算记录');
  return {
    orderNo: payload.tno,
    clearingRefNo: payload.clearing_ref_no,
    instructingBank: payload.instructing_bank,
    clearingStatus: payload.clearing_status
  };
}

关于 QRPH 商户 API 接入的完整字段说明和验签流程,可以看QRPH 商户 API 接入流程这篇,里面有更完整的接口清单。

对接实时支付清算系统的技术检查清单

结合我们踩过的坑,给准备接入或者正在排查对账问题的技术团队列几条实操建议:

• 对账主键用清算参考号,不要用"金额+时间窗口"去模糊匹配,交易量上来之后模糊匹配一定会出问题;
• 区分"清算失败"和"清算通过、结算处理中"两种状态,给不同的重试和告警策略,不要用一个笼统的失败状态覆盖所有场景;
• 弄清楚接入的通道是逐笔清算还是批量清算,这直接决定了重试间隔和对账频率该怎么设计;
• 落库时把清算机构返回的原始状态码原样保留,不要在业务层做二次归类之后就丢弃原始信息,后续排查纠纷需要原始码;
• 核实服务商的牌照资质,这一点容易被忽略,但直接决定了清算记录是否可审计、可追溯。

菲律宾对 BSP OPS/EMI 持牌机构有明确的清算参与方资质要求和持续合规义务,选服务商时建议直接核实对方的牌照信息和主体资质,而不是只看接口文档写得好不好看。

如果你还在评估要不要自建清算对账逻辑,或者想先看看 QRPH 商户接入的完整流程,可以先读QRPH 接入指南这篇,里面有申请材料和开通步骤。

常见问题

清算失败和结算失败是一回事吗?

不是。清算失败通常在交易发起后很快就能拿到明确的错误码,比如账户信息校验不通过;结算是清算通过之后,资金在机构间账户完成最终划转的环节,商户系统一般感知不到结算本身的异常,只能通过对账发现记录不一致。

QRPH 交易的清算是由谁来做的?

QR Ph 本身是二维码互通标准,底层资金指令走的是 InstaPay 或相应通道既有的清算轨道,由自动清算机构核对交易指令,再由结算系统完成资金最终划转。

商户能不能只看回调状态判断资金到账?

不建议。回调状态大多反映的是清算层面的确认,如果业务逻辑直接把"清算通过"等同于"资金已到账",在个别边缘场景下可能会和财务实际记录对不上,建议以清算参考号为主键做独立对账。

清算参考号和商户自己的订单号有什么区别?

商户订单号是商户系统内部生成的业务标识,清算参考号是清算机构在核对交易时生成的跨机构凭证。跨机构核对纠纷时,清算参考号才是各方都认的凭证,订单号只在商户自己系统内有意义。

逐笔清算和批量清算,商户接入时需要注意什么不同?

逐笔清算通道适合对实时性要求高的场景,商户的回调和对账逻辑可以按笔处理;批量清算通道按批次提交,商户对账逻辑需要按批次窗口去核对,而不是按单笔时间去猜测。

选支付服务商时,清算这一层要怎么核实对方靠不靠谱?

可以直接问对方的牌照资质和清算参与方身份,持牌的 OPS/EMI 机构因为要接受监管审计,清算记录和结算记录是可追溯的;如果对方讲不清楚自己在清算链条里的具体角色,只强调"到账快",建议多留一个心眼。

清算记录出现异常,商户自己能查到哪一步?

商户系统能查到的,通常止步于清算参考号和状态码这一层;再往下涉及机构间账户调整的部分,需要通过服务商或清算机构协助核实,商户自己的系统看不到银行间账户的具体变动。

如果你的团队正在对接 QRPH、InstaPay 相关的收款或代付通道,想具体核对某一笔交易的清算记录,或者想了解我们作为持牌机构的接入方案,欢迎联系我们的技术团队,我们可以提供具体的接口文档和对接支持。

Telegram:@LouisSMARTPAY  |  邮箱:[email protected]