SMARTPAY

QRPH代收代付手续费结构对比:收款与出款是否分开计价?(2026)

我在马尼拉带技术团队对接支付这几年,见过不少商户只问一句"QRPH手续费多少",拿到数字就当成全部成本。真正跑起来对账才发现,这个数字往往只覆盖代收(收款)这一段,代付(出款)是另一套计价逻辑,常常没写进最初的报价单里。关于单笔收款费率本身怎么拆,站内已经有一篇QRPH手续费怎么算专门讲单一费率的构成;这篇换个角度,专门聊代收和代付放在一起看的时候,费用结构差在哪、哪些成本项是代付独有的、交易量上去之后又能谈到什么程度的空间。

先把前提说清楚:代收代付是两条独立的资金路径,不是"一套费率打包服务"。收款走的是付款人钱包或银行到商户账户的清算路径,出款走的是商户账户到收款人钱包或银行账户的路径,中间经手的持牌机构、风控环节、失败重试机制都不一样,费用结构自然也不是同一套逻辑在套用。

为什么"代收"和"代付"不能套同一个费率去理解

很多商户第一次接触QRPH,是从收款场景开始的——上线一个收款二维码,看到报价单上一个费率数字,就默认这是"QRPH的费率",以后所有涉及资金进出的场景都按这个数字估算。等业务做到需要批量发佣金、发工资、给上游供应商付款的阶段,才发现代付这段完全是另一张价目表,甚至要重新走一轮商务谈判。

这不是哪家机构故意藏信息,而是代收和代付本来就是两类业务:代收是"帮你收钱进来",代付是"帮你把钱发出去并对收款人身份负责"。后者涉及的合规动作更重,计价逻辑也更容易按场景、按批量规模单独定价。把两段费率混在一起理解,是我见过商户预算测算里最常见的误差来源。

代收(收款)侧:费用通常叠在哪几层

代收这一段,钱从付款人钱包出发,经过QRPH清算网络,落到收单方(给商户提供收款服务的持牌机构)名下,再结算给商户。商户看到的"收款费率",本质上是收单方对这整段服务收取的费用,里面已经打包了清算网络本身的处理成本、基础交易风控,以及收单方自身的运营成本。多数场景下这是按单笔订单计价,维度相对单一,测算起来也比较容易。

正因为代收是商户最先用起来、也最先感知到费用的环节,很多人会不自觉地把这段费率当成"全部成本"。但一个只做收款的纯电商商户,和一个既要收款又要批量出工资、出佣金的商户,成本结构从一开始就不是一回事。

代付(出款)侧:为什么这段经常比想象中贵

代付的链路反过来:商户账户发起付款指令,经出款机构处理,落到收款人的钱包或银行账户。多出来的成本项主要来自三处:一是实名核验和反洗钱筛查,每一笔出款都要走一次收款人身份与风险等级的判断,这是收款环节不需要重复做的功课;二是失败重试与退回处理,账户状态异常、账户不存在、风控拦截导致的失败单需要人工或系统重新发起,这部分处理成本通常会摊进代付费率;三是批量处理本身的系统资源消耗,工资代发、佣金结算这类一次性批量发起的场景,文件解析、逐笔校验都要占用处理能力,具体操作细节在批量出款方案那篇拆得更细。

出款环节对商户现金流周转的影响,和之前写的D0结算原理逻辑相通——资金进出节奏不同,预留的周转资金也要跟着调整。所以建议:不要假设代付是代收的附赠服务,更不要假设同一个费率能顺带覆盖双向场景。报价单只写一个笼统的"手续费"时,一定要追问覆盖的是单向还是双向。

阶梯费率与交易量档位:规模怎么影响议价空间

无论代收还是代付,持牌机构给出的报价很少是一刀切的固定数字,更常见的是按月交易量或单笔金额分出档位——档位越高,议价空间越大;档位越低,反而可能按最低消费的标准收费。代付这一侧的阶梯逻辑尤其明显,因为批量出款本身就是规模化场景,机构更愿意为高频、批量的商户单独定价,而不是套用零散单笔的标准报价。

下表对比了不同规模和接入模式下,代收代付两段的计价方式差异,帮大家先判断自己大致属于哪一类,再决定该往哪个方向去谈商务条件。

商户规模/接入模式代收计价方式代付计价方式议价空间
初创/低频小额商户按单笔订单计价,接近标准报价按单笔计价,通常无批量优惠较小,先跑出稳定交易量再谈
成长期电商/订阅类商户按月交易量分档,阶梯递减按出款批次+笔数双重计价中等,可就批量批次打包报价
工资代发/佣金结算类商户收款量通常较小,接近标准档位按批量规模单独报价,常见打包方案较大,出款是核心诉求,机构更愿配合
聚合网关接入商户网关方统一报价,内部再分润网关方统一报价,代付条款需单独确认取决于网关议价能力,商户直接谈判空间有限
自营直连持牌机构商户可直接就交易量谈阶梯条款可直接就批量规模谈打包方案最大,但需要自身具备对接与合规能力

代收代付成本项对照:同一通道下两段账单差在哪

把代收和代付放到同一张表里比,更容易看出两段差在哪一类成本项上,而不是简单比"数字大小"。

维度代收(收款)代付(出款)
计价颗粒度以单笔订单为主单笔+批量混合,常见按批次叠加笔数
风控环节基础交易风控,核验付款方设备与行为实名核验+反洗钱筛查,核验收款方身份
失败处理成本相对少见,多为超时未支付失败重试、退回处理较常见,人工介入概率更高
账户链路复杂度商户收款账户单侧校验商户出款账户+收款方账户信息双侧核验
对账方式以进账流水为主,结构相对简单出账流水+失败回执需交叉核对

这张表也解释了两类常见踩坑。一是谈判只盯代收费率压价,代付条款写得含糊,批量出款时才发现多了一道审批或一笔操作费。二是把聚合网关的打包报价当成持牌机构的原始报价——网关对外报一个数字,背后两段成本依然分开,交易量变化时商户往往缺少对照依据重新议价。

合规持牌在费率背后到底意味着什么

持牌支付机构同时持有菲律宾央行颁发的OPS(运营支付系统)和EMI(电子货币机构)资质,代收代付两段服务背后对应的是两套合规义务,而不是同一张牌照通吃所有业务场景。

代收这一侧,持牌机构要对交易本身的真实性和付款人风险负责;代付这一侧,持牌机构要对收款人身份核验和反洗钱义务负责,这是监管对资金出口环节天然更严格的要求。这也是为什么一些表面报价很低的非持牌代理方案,往往只做了代收这一半,出款环节要么外包给第三方、要么绕开合规核验直接转账,看起来省了一笔费用,实际上把资金安全的风险转嫁给了商户自己。

判断一份代收代付报价是否完整,先看它有没有把OPS和EMI两类义务对应的服务都写清楚,而不是只看最终那个数字够不够低。

我们在接入前的尽调清单里,会要求商户确认对接方的资质覆盖范围,这部分材料准备和开通流程,之前在QRPH商户开通的申请材料清单里也写过,逻辑是一致的——先确认资质边界,再谈费率细节。

系统对接视角:两段费用怎么在代码里核算清楚

从技术团队角度看,代收代付费用不是财务事后算出来的,而是应该在下单和出款请求的那一刻,就把订单金额、费用归属(代收段还是代付段)一起落到数据库里,后续对账才不会扯皮。下面是发起QRPH代收订单的请求示例,关键是把业务类型字段一起传下去,方便对账系统按段拆分统计:

curl -X POST https://apix.example.com/api/qrph/collect \
  -H "Content-Type: application/json" \
  -d '{
    "merid": "M100293",
    "tno": "COLLECT20261003001",
    "amt": "1000.00",
    "biz_type": "collection",
    "notify_url": "https://merchant.example.com/notify/collect",
    "sign": "..."
  }'

对应的代付(出款)请求字段结构类似,但业务类型和收款方信息校验环节不同,系统里最好单独拆一个请求方法,而不是复用代收的下单逻辑:

const axios = require('axios');
const crypto = require('crypto');

function buildSign(params, secret) {
  const sorted = Object.keys(params).sort()
    .map(k => `${k}=${params[k]}`).join('&');
  return crypto.createHash('md5').update(sorted + secret).digest('hex');
}

async function initiatePayout(order) {
  const params = {
    merid: order.merid,
    tno: order.tno,
    amt: order.amt,
    biz_type: 'payout',
    receiver_account: order.receiverAccount,
    receiver_name: order.receiverName,
  };
  params.sign = buildSign(params, process.env.API_SECRET);

  const resp = await axios.post('https://apix.example.com/api/qrph/payout', params);
  // 落库时把 biz_type 一起记下来,对账脚本按 collection / payout 分组统计费用
  return resp.data;
}

验签和回调处理的细节,以及生产环境切换前要确认的几个关卡,在QRPH商户API接入与验签流程里写过完整流程,这里不重复展开。核心思路就一句话:代收代付在系统层面就该是两条独立的记账链路,费用归属从下单那一刻就要分清楚,不要等月底对账再靠人工拆分。

常见问题

代收和代付是分开计费还是合并算一笔?

绝大多数持牌机构是分开计费的,代收按收款场景计价,代付按出款场景单独计价,两者对应的合规动作和处理成本本来就不一样。如果有方案说"一个费率全包",一定要让对方书面写清楚代付部分具体怎么算。

出款失败或被退回,这一笔还要不要重新计费?

要在谈判阶段确认清楚,不同机构处理方式不同:有些对未成功的出款不收费,有些会对需要人工排查的失败单单独计费。建议在合同里明确失败单的计费规则,避免事后争议。

大额批量代付能不能申请更低的费率?

可以尝试,批量规模本身就是议价的筹码,尤其是工资代发、佣金结算这类有规律、可预测的批量场景,机构通常更愿意配合打包方案。但前提是商户要能提供相对稳定的交易量预期,临时性的大额批量很难谈到长期阶梯条款。

代收费率低,代付费率是不是也会跟着低?

不一定。两段费率是独立定价的,代收做得便宜不代表代付也便宜,反而有些机构会用低代收费率吸引商户接入,代付这一段再单独谈价。签约前最好让对方把两段费率都明确写在同一份报价单上,分开对比。

怎么在合同里确认两段费率不会被捆绑销售误导?

最直接的办法是要求报价单把"代收"和"代付"拆成两行列出,各自写明计价方式(按笔/按批次/按月交易量分档),而不是只给一个笼统的"手续费"数字。有疑问的条款,要求对方书面补充说明。

自营直连持牌机构和用聚合网关,两种模式下费用结构一样吗?

计价逻辑是一样的——都是代收代付分开算,但议价空间不同。自营直连可以直接就自己的交易量和持牌机构谈阶梯条款,聚合网关则是网关方统一报价,商户议价的余地取决于网关自身的议价能力,这部分在选型阶段就要想清楚。

刚起步交易量不大,现在就该关心代付费率结构吗?

建议尽早了解,哪怕暂时用不到批量出款。很多商户是业务跑起来之后才突然需要发佣金、发工资,到那时候才发现当初签的方案里代付条款模糊不清,再去重新谈判反而更被动。提前把两段费用结构摸清楚,后续扩展场景会顺畅很多。

如果你正在评估QRPH代收代付方案,或者已有报价单想找人一起拆解两段费率是否合理,可以直接联系我们——Telegram @LouisSMARTPAY,或邮箱 [email protected],我们持有BSP的OPS和EMI牌照,可以把报价单拿来对照着看。

相关推荐