SMARTPAY

GCash和QRPH怎么选:菲律宾商户收款通道对比

在马尼拉做了几年本地支付对接之后,我被商户问得最多的一句话是:"我们到底该先接GCash,还是先上QRPH?"每次听到这个问题,我都想先打断一下——这不是一道单选题,很多商户一上来就把两个通道当成互相替代的竞争关系,结果要么重复投入,要么漏接了该接的那一个。GCash和QRPH解决的是完全不同层面的问题,连接逻辑也不一样,很多时候是可以、甚至应该同时接入同一套收银系统的。这篇我想从商户接入决策的角度,把两条通道拆开讲清楚:各自解决什么问题、接入复杂度差在哪、什么时候必须两个都上、什么时候可以先放一放。

如果你更关心扫码那一刻用户体感上的差别,可以看我们之前写的QRPH和GCash二维码体验差别(消费者视角),那篇是从消费者角度实测的;今天这篇是给商户和技术负责人看的接入决策版本,两篇可以对照着读。

GCash是什么通道:单一钱包的直连逻辑

GCash本质上是一个独立的电子钱包App,商户接入GCash,接的是"这一家钱包"的收款能力。不管是GCash原生直连还是通过聚合网关跳转,背后连接的都是同一个发行机构的账户体系。好处是链路相对单一,商户只需要和一套接口、一套结算规则、一套风控逻辑打交道,我们之前详细拆过GCash原生直连通道的接入方式和优势,核心就是"少一层跳转、少一层不确定性"。

局限也很直接:GCash只能收GCash用户的钱。菲律宾本地用户里,相当一部分人主力钱包不是GCash,而是银行App或者别的电子钱包。只接GCash,相当于只打开了消费群体的一部分入口。

QRPH是什么通道:央行统一二维码标准,一码连多家

QRPH不是某一家公司的产品,它是菲律宾央行(BSP)牵头的统一二维码支付标准。商户生成一张QRPH码,理论上任何接入了QRPH标准的银行App或电子钱包用户都可以扫这同一张码完成支付,不用商户一家一家去对接。我们在QRPH二维码支付科普里写过它的技术原理,简单说就是央行把二维码的数据结构和清算路由标准化了,相当于给整个市场定了一套"通用插座"。

QRPH的好处是覆盖面广,一张码能接住更多来源的用户;代价是商户要接入的是一套跨机构的清算体系,参与方越多,出问题时的排查链条也相对更长,QRPH商户开通条件里对资质和审核要点有更细的说明,接入前建议先核对一遍。

核心差异:连接模式、覆盖范围与接入复杂度

把两者放在一张表里看会更清楚:

维度GCashQRPH
连接性质单一钱包直连央行统一标准,多机构互通
覆盖范围仅GCash用户已接入QRPH的银行App与电子钱包用户
接入主体GCash官方或其授权渠道持牌收单机构/通道商,底层对接央行清算网络
技术对接复杂度单接口、单套验签规则路由逻辑更复杂,但多由收单机构在网关层封装
典型适用场景用户画像明确以GCash为主的业务线下门店、跨渠道零售、需要覆盖多钱包/银行用户的场景

需要澄清一个常见误解:QRPH覆盖面广,不代表它在每一笔交易的体验或到账路径上都优于GCash。两者是不同维度的指标,不能简单说谁"更好",只能说谁更适合当前的用户结构。

能不能两个都接?并存架构怎么设计

答案是可以,而且很多成规模的商户最终都会走向"两个都接"。关键在于怎么设计并存架构,而不是来回切换。常见的做法是通过一套聚合支付API统一下单接口,后端根据订单场景或用户选择的支付方式,把请求路由到GCash通道或者QRPH通道,商户侧的订单系统、对账系统不需要为每个通道各写一套逻辑。

并存架构里有两个容易被忽略的点:一是两个通道的结算周期和到账规则可能不完全一致,财务对账的时候要分开核对,不能用一套口径去套两个通道;二是风控规则也要分开配置,GCash和QRPH各自的限额、拒付处理流程不是一回事,混在一起容易出现"某个通道报警了,但你以为是另一个通道的问题"这种排查混乱。

从合规角度看,不管接的是GCash还是QRPH,背后承接资金的机构都需要具备BSP认可的OPS(运营支付系统)或EMI(电子货币机构)资质。商户在选通道商的时候,这一点比界面好不好看、接口文档全不全更该优先核实。

不同业务规模该怎么选

没有一个通道适合所有商户,下面是我们在实际项目里总结的一个粗略对照,供参考:

业务阶段/规模优先接入原因
刚起步,用户以GCash为主的社交电商/小微商户先接GCash接入链路简单,用户画像集中,投入产出比高
线下门店、连锁零售优先QRPH,GCash可并行线下客流的钱包/银行App分布分散,单一钱包会漏掉相当一部分客人
跨区域/跨平台中大型商户两者并存用户结构复杂,单通道覆盖不足,需要统一聚合层管理
B2B、订阅制或固定客户群业务视客户主用钱包而定,不必强求两者都接客户结构固定时,盲目多接通道只会增加维护成本

我们见过的一个典型反例是:商户一上来就要求把市面上能接的通道全部接满,结果维护成本、对账成本远超实际收益。通道数量不是越多越好,关键是匹配自己的用户结构和业务阶段。

接入技术路径与验签逻辑

从技术层面看,GCash和QRPH在聚合网关下的接口调用方式往往非常接近,区别主要体现在请求里的通道参数和回调里的字段结构。一个典型的下单请求大致是这样:

curl -X POST https://api.smartpay-gateway.com/v1/orders \
  -H 'Content-Type: application/json' \
  -H 'Merchant-Id: MCH1000XXXX' \
  -d '{
    "merid": "MCH1000XXXX",
    "tno": "ORDER20261003001",
    "channel": "QRPH",
    "amt": "100.00",
    "notify_url": "https://yourdomain.com/callback",
    "sign": "A1B2C3..."
  }'

把channel字段换成GCASH,其余结构基本不变,这也是为什么很多商户会选择先用同一套聚合网关把两个通道都接上,而不是各写一套对接代码。回调验签的逻辑通常也是共用的:

const crypto = require('crypto');

function verifySign(params, secretKey) {
  const { sign, ...rest } = params;
  const sorted = Object.keys(rest).sort()
    .map(k => `${k}=${rest[k]}`)
    .join('&') + `&key=${secretKey}`;
  const localSign = crypto.createHash('md5').update(sorted).digest('hex').toUpperCase();
  return localSign === sign;
}

// channel 字段是 GCASH 还是 QRPH,验签逻辑完全一致
// 这是技术上支持"两个通道并存不用双倍开发量"的关键原因

需要提醒的是,不同通道商的字段命名和验签算法会有差异,上面只是示意结构,实际对接前一定要以对方提供的接口文档为准,不要照抄示例代码直接上生产。

常见问题

先接GCash还是先接QRPH?

看用户结构。如果现有客户或目标客群明显以GCash为主,先接GCash成本最低;如果是线下门店或客群分散,QRPH的覆盖面优势会更明显。没有标准答案,建议先看一下自己现有订单或意向客户的钱包分布再决定。

两个通道可以用同一个商户后台管理吗?

如果走的是聚合网关接入,通常可以在同一个后台看到两个通道的订单、对账和报表,但底层的结算规则、限额、风控策略仍然是分开的,后台只是统一了查看入口,不代表两个通道的业务规则被合并了。

QRPH覆盖的银行/钱包是不是一定比GCash多?

从机构数量上看通常是的,因为QRPH本身就是设计给多家机构接入的统一标准。但具体到某一类用户群体的覆盖效果,还要看目标客群实际使用哪些App,不能只看机构数量就下结论。

已经接了GCash,还有必要再接QRPH吗?

取决于你是否发现有潜在客户因为"没有GCash"而放弃付款。如果客群高度集中在GCash用户,暂时不接QRPH也不会有明显损失;如果业务正在往线下或跨平台扩展,建议把QRPH排进接入计划。

QRPH的二维码和GCash的二维码是同一个吗?

不是同一个概念。GCash可以有自己的原生二维码,也可以生成符合QRPH标准的码;QRPH是统一标准,理论上任何接入该标准的机构生成的码都遵循同一套数据结构。商户在选择生成哪种码时,需要和通道商确认清楚当前用的是哪一套。

小商户有没有必要同时接两个通道?

不一定。如果业务体量小、客群集中,维护两套通道的对账和风控反而会增加不必要的负担。建议先用单一通道跑稳,等客群结构变复杂或体量上来之后再考虑扩展。

换通道或新增通道需要重新签约收单机构吗?

一般需要走一遍该通道对应的商户开通流程,具体材料和审核要点因通道商而异,建议提前向对接的通道商确认清楚一遍,避免临时缺材料耽误上线时间。

GCash和QRPH不是竞争对手,是两种不同的接入逻辑,很多商户最终的答案是"两个都接,但分开管理"。如果你正在纠结先接哪个、或者想看看现有业务结构适合哪种组合,可以找我们聊聊,我们是持BSP OPS/EMI资质的本地支付服务商,可以直接帮你评估:Telegram联系@LouisSMARTPAY,或邮件[email protected]。

相关推荐