SMARTPAY

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

商户后台里经常有同事问我同一个问题:"GCash和Maya,我们新业务到底接哪个?"这句话听起来简单,但背后其实压着好几层完全不同的判断——API好不好接、审核会不会卡人、钱什么时候能到账、费率结构划不划算、这类业务究竟更适合走哪条通道。如果你想看的是作为普通用户"用哪个钱包体验更好",可以直接看GCash与Maya的用户视角全面对比,那篇讲的是功能和使用体验。这篇我们只站在商户和技术负责人的角度,把对接、审核、结算、费率这几件真正影响业务决策的事拆开讲清楚。

先说清楚:这不是"哪个钱包更好用"的问题

消费者选钱包,看的是转账方不方便、功能全不全、身边朋友用哪个。商户选通道,看的是另一套指标:能不能稳定地把钱收进来出得去,审核会不会把业务类型挡在门外,结算周期是否匹配现金流节奏。我们接触过不少刚落地菲律宾的商户,最初的判断逻辑是"GCash用户多就接GCash",这在消费侧没错,放到商户侧却常常出问题——用户规模大,不代表审核宽松,也不代表结算节奏适合你的资金周转。这篇文章就是想把这个认知差补上。

一张表,看懂商户视角的核心差异

下面这张表是我们团队在给商户做通道选型时内部对齐用的版本,维度上只讲相对差异和特点,不代表任何一方的官方承诺,具体条款请以双方签署的商户协议为准。

维度GCash 商户侧特点Maya 商户侧特点
API 成熟度原生对接经过多年迭代,接口和错误码体系相对完善,第三方对接经验积累较多接口能力也在持续完善,部分能力(尤其是银行类产品联动)更新节奏较快,文档细节上有时需要配合对接经理确认
商户审核门槛对特定高风险行业(博彩、成人内容等受限类目)审核较为谨慎,材料齐全的常规电商/服务类商户通过率相对可预期审核逻辑类似,但因为同时承担电子货币与银行类业务,部分材料要求与银行侧KYC标准联动,流程环节会多一步
结算速度与路径原生直连下结算路径相对直接,具体到账周期取决于商户协议中约定的结算频次结算路径同样取决于商户协议,但因为背靠自身银行牌照,部分资金可以留在体系内流转,减少一次出入账环节
费率结构逻辑费率通常按交易类型(扫码、原生直连、代付)分别定价,结构相对清晰费率结构里会出现按商户等级、交易规模分档的情况,具体档位需要和商户经理逐项确认
适合的业务规模从中小商户到大型电商都有成熟接入路径对需要银行账户联动、资金留存体系内运作的商户更有优势
开发者支持社区和第三方对接经验相对丰富,踩坑记录多,排查效率高官方支持响应也在改善,但第三方经验积累相对少一些,排查时更依赖对接经理
无论选哪一边,前提都是同一个:GCash和Maya背后的运营主体都必须持有BSP授予的EMI(电子货币机构)牌照才能合法从事电子货币业务,这是菲律宾电子支付行业最基础的合规门槛。SMARTPAY作为持有BSP认可的OPS/EMI资质的机构,在帮商户做通道选型时,第一步永远是先确认对方的牌照状态,而不是先看费率数字。

API对接难度与文档成熟度:两种完全不同的开发体验

从纯技术对接的角度讲,GCash原生API在市面上已经跑了很多年,无论是签名规则、错误码体系,还是沙盒环境的稳定性,第三方服务商和开发者社区都积累了相当多的实战经验,遇到问题能比较快定位到底是签名错了、参数格式不对,还是回调地址配置有误。我们在GCash 收款 API 对接教程里也写过完整的对接流程,基本上一个熟悉支付接口的开发团队,按文档走一遍就能跑通。Maya这边的情况略有不同——它的商户端产品线更复杂,既有纯收单能力,也有和自家银行账户联动的能力,这意味着同一个"收款"需求,底层可能对应不同的产品形态,对接前最好先跟商户经理确认清楚你要接的具体是哪一类接口,相关细节可以参考Maya 商户收款对接指南。

实际项目里,我们经常会用一套中间层去统一两个通道的签名逻辑,减少业务代码里的分支判断。下面是一个简化示例,展示的是两个通道在签名方式上的典型差异(字段和密钥均为示意,实际以各自最新接口文档为准):

const crypto = require('crypto');

function buildSignature(channel, params, secretKey) {
  const sortedKeys = Object.keys(params).sort();
  const raw = sortedKeys.map(k => `${k}=${params[k]}`).join('&') + `&key=${secretKey}`;

  if (channel === 'gcash') {
    // GCash 原生通道常见做法:字段排序后拼接,MD5 摘要并转大写
    return crypto.createHash('md5').update(raw).digest('hex').toUpperCase();
  }

  if (channel === 'maya') {
    // Maya 侧部分产品线采用 HMAC-SHA256,字段里通常多一层商户参考号
    return crypto.createHmac('sha256', secretKey).update(raw).digest('hex');
  }

  throw new Error('unsupported channel: ' + channel);
}

async function createOrder(channel, orderParams, secretKey, endpoint) {
  const sign = buildSignature(channel, orderParams, secretKey);
  const payload = { ...orderParams, sign };

  const res = await fetch(endpoint, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(payload),
  });
  return res.json();
}

对应的下单请求示意如下:

curl -X POST https://apix.example.com/api/v1/orders \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "gcash",
    "merid": "M20261003XXXX",
    "order_no": "ORD20261003001",
    "amt": "100.00",
    "notify_url": "https://yourdomain.com/callback/gcash",
    "sign": "B61FA7...9C3D"
  }'

如果你的团队要同时接入两个通道,建议一开始就把签名、回调、状态码这几层抽象成统一接口,而不是让业务代码里到处散落 if-else 判断,这部分如果想看更系统的选型思路,也可以参考菲律宾聚合支付 API 怎么选。

商户审核门槛:谁的材料要求更松,谁卡得更严

审核这件事,两家大方向一致——都要走KYC实名核验、看经营资质材料、对特定高风险行业设限。差别更多体现在流程环节数量和材料联动的复杂度上。GCash这边,对于常规电商、服务类、SaaS类商户,只要材料齐全、经营主体清晰,审核流程相对直接;但对博彩、成人内容、部分跨境资金调度类业务,审核会明显更谨慎,这类商户准入门槛可以对照GCash Business vs Maya Negosyo 对比里关于商户账户产品差异的部分提前预判。Maya这边因为背后同时牵涉电子货币业务和银行业务,部分商户材料会涉及银行侧的KYC联动要求,流程环节可能会多一道,但好处是一旦通过,资金在体系内留存和调度的灵活度也会相应提升。

这里要强调一点:不管审核流程松紧,最终的合规底线都是同一套——BSP对OPS(支付业务运营商)和EMI牌照持有机构的要求。商户在选通道时,与其纠结哪边"更容易过",更应该关注自己的业务类型本身是否属于受限类目,如果属于,无论接哪个通道,该补的合规材料都少不了。

结算速度与资金到账路径:不是一句"T+几"能说完的

很多商户问结算速度,其实问的是"钱多久能用"。这没有通用答案,因为结算速度取决于三件事:商户协议约定的结算频次、通道本身的清算机制,以及资金最终落地的账户类型。GCash原生直连下,结算路径相对直接,资金从交易完成到进入商户结算账户的中间环节比较清楚;Maya因为自身持有银行牌照,部分商户的资金可以在体系内流转后再出账,少一次跨机构清算环节,但能不能享受这个便利,取决于商户签的是哪一类账户产品。我们都不建议商户在没有书面确认结算周期之前,就按固定数字安排现金流计划——结算速度应该写进商户协议,而不是靠口头预期。

费率结构:两套不同的计价逻辑,不是一个数字的事

费率对比是商户问得最多、也最容易被简化误导的一环。真正该关注的不是"哪家便宜几个点",而是费率结构本身的逻辑。GCash这边的费率通常按交易类型分别定价——扫码收款、原生直连、代付出款各自有自己的计价方式,结构相对清晰,商户容易按业务场景提前预估成本。Maya这边的费率结构里,会出现按商户等级、交易规模分档计价的情况,也就是说同一类交易,不同体量的商户可能适用不同档位,这意味着费率不是一个固定值,需要和商户经理逐项确认清楚当前适用的档位,以及未来交易规模变化会不会触发档位调整。业务处于快速增长阶段时,这种分档机制既可能是优势,也可能是变量,务必在签商户协议之前问清楚。

哪类业务该优先接哪个通道

结合上面几个维度,我们给几类常见业务的优先建议整理成一张表,供参考,具体仍要结合实际审核结果和双方商户协议条款判断:

业务类型建议优先考虑理由简述
独立站/电商结账页GCash 原生直连为主,Maya 作为补充通道用户覆盖面广,API对接经验成熟,适合作为主通道先跑起来
游戏充值/订阅类高频小额交易视到账诉求而定,两者均可,优先看费率分档是否匹配交易规模交易频次高,费率结构的分档逻辑对总成本影响更明显
需要资金长期留存体系内调度的业务可重点评估 Maya 的银行联动能力背靠自身银行牌照,资金调度路径可能更灵活
跨境代收代付、工资/佣金批量代发两者都要评估,但优先确认各自的代付审核门槛代付场景对审核严格度和限额更敏感,不能只看收款侧条件
直播打赏/内容付费需提前确认双方对该类目的审核态度部分内容类业务可能落入受限或需要额外材料的类目

实操中我们也见过不少商户两个通道都接,GCash做主力入口,Maya做补充或特定场景的备选。好处是风险不押在一个通道上,代价是对账和风控逻辑要同时维护两套,回调字段、状态码都不完全一样。建议接入第二个通道之前,先确认对账和风控系统有没有做好"多通道归一"的设计,而不是等接完才发现数据格式对不上。

常见问题

GCash和Maya可以同时接入吗,需要注意什么?

可以同时接入,很多中大型商户也确实两边都接。需要注意的是两个通道的回调字段、错误码、结算周期都不完全一致,建议在业务层做一层统一抽象,把渠道差异封装起来,避免业务代码里散落大量渠道判断逻辑。

刚起步的小商户,应该先接哪一个?

如果没有特殊的资金留存或银行联动需求,通常建议先接GCash原生直连,第三方对接经验和踩坑记录相对丰富,排查问题效率更高,等业务规模和需求明确之后再评估是否补充接入Maya。

两个通道的审核会不会因为我同时申请而互相影响?

一般不会直接互相影响,两边的审核体系是独立的,但如果你的业务类目本身属于受限或高风险类目,很可能在两边都会遇到同样的审核谨慎度,这不是"互相牵连",而是因为合规底线本身是一致的。

Maya的银行联动能力,对一般电商商户有实际意义吗?

对纯电商结账场景来说,这个优势不一定明显;但如果业务涉及资金在体系内多次调度,或希望减少一次跨机构清算环节,这个能力会比较有价值,建议结合自己的资金流转需求判断,而不是单纯因为"听起来先进"就选它。

两个通道的费率,能不能直接拿数字比大小?

不建议这样比较。GCash按交易类型分别定价,Maya按商户等级和交易规模分档,两套逻辑的计价基础不一样,脱离实际交易结构去比"谁更便宜"容易得出误导性结论,正确做法是把交易量级和类型代入两边费率表分别测算。

已经接了GCash,再加Maya需要重新走一遍商户审核吗?

需要。两个通道的商户资质是分别审核的,即便你已经通过了GCash的审核,接入Maya仍然需要单独提交材料走它自己的审核流程,不存在"一边通过另一边自动通过"的情况。

如果你正在为新业务做通道选型,或者已经接了一边想评估要不要补充另一边,欢迎直接找我们聊具体情况:Telegram @LouisSMARTPAY,或邮箱 [email protected],我们可以结合你的业务类型和交易规模给出更具体的判断。

相关推荐