如何在菲律宾通过 GCash 接入代收代付服务：从代收回调到代付出款的完整闭环指南｜币付

在菲律宾做业务，GCash 往往是最核心的本地支付方式之一。但真正能长期跑量的，并不是“接上一个收款按钮”，而是把代收 + 代付 + 对账 + 结算做成闭环：订单状态最终一致、异常可快速定位、财务能顺畅对账、现金流可预期。

币付 Bifu 为商户提供菲律宾代收代付能力，支持通过 GCash 完成收款与出款，并可按业务与风控评估匹配更快结算策略，例如同日结算、D0 等。本文从落地角度出发，给你一份可以直接按清单上线的接入指南，同时也覆盖 QRPH 聚合场景，便于你用一套闭环跑通多通道。

实时费率表：GCash & QRPH

以下为币付的实时费率表代码，包含 GCash 与 QRPH：

[rate-table type="all"]

一、先确认你要解决的问题：要接口，还是要稳定闭环

很多商户上线后遇到的麻烦，基本都集中在以下几类：

掉单与争议单：用户说已付款，但系统没确认；客服只能人工查。
重复入账：回调重复触发，导致重复加点、重复发货、重复开通。
对账困难：支付成功、入账成功、可结算口径混在一起，财务对不上。
结算不可预期：资金何时可用不清晰，现金流压力变大。

要长期稳定跑量，你需要的是闭环：代收确认可靠 + 代付可追踪 + 对账口径清晰 + 结算规则可预期。这也是币付在对接 GCash、QRPH 聚合码等通道时最强调的落地标准。

二、接入前准备：把业务信息与技术配置一次准备齐

1）商户侧需要准备的业务信息

业务类型：电商 / 订阅 / 数字内容 / 平台 / 充值，并简述你的交易链路。
交易结构：单笔金额区间、日订单量预估、峰值并发、退款或拒付预期。
是否需要代付：仅代收，还是代收 + 代付闭环。平台型业务通常更需要闭环。
结算诉求：是否希望匹配更快结算策略，例如同日结算、D0 等。

2）技术侧必须准备的基础配置

notify_url 回调地址：长期稳定可访问，建议具备监控、告警与容灾。
服务器时间同步：避免签名或时间戳校验失败。
日志留存：至少保留商户订单号、通道订单号、回调原文、验签结果、处理结果。
幂等存储：确保同一订单重复回调只处理一次。

3）为什么要考虑 QRPH 聚合

GCash 是高频必接，但很多线下与多钱包场景更适合 QRPH。用币付做聚合，能让你在不重写业务闭环的前提下，同时覆盖 GCash 与 QRPH 等通道，统一回调、统一对账、统一结算口径。

三、代收 Pay-in 接入流程：从下单到最终确认

Step 1：服务端创建订单，作为唯一可信入口

强烈建议由服务端创建订单并返回支付参数，避免前端伪造与金额被篡改。订单建议至少包含：

merchant_order_no：商户订单号，全局唯一，可追溯。
amount / currency：金额与币种。
user_id：你的系统内部用户标识。
biz_type：业务类型标识，用于风控分层与对账汇总。

Step 2：发起支付，前端显示成功不等于支付成功

用户进入支付流程，只代表开始支付。最终结果必须以回调通知或订单查询确认。不要用“前端返回成功”直接给用户加点、发货或开通会员。

Step 3：回调通知处理，验签与幂等是稳定性的底线

回调处理必须做到三点：

验签：签名不通过直接拒绝；订单号、金额、状态、时间戳等关键字段必须参与校验。
金额校验：回调金额必须与下单金额一致，不一致直接标记异常并告警。
幂等：同一订单可能重复回调，多次通知只能入账一次。

建议的稳健顺序：回调先落库，写入订单状态与通道单号 → 再触发业务动作，发货、加点、开通 → 最后返回回调成功响应。这样最不容易掉单与重复入账。

Step 4：订单查询兜底，终结扣款未到账的争议

高频业务一定会遇到网络抖动或回调延迟。必须做查询兜底：

对“处理中 / 超时”订单设置定时查询任务，直到收敛到最终态：成功 / 失败 / 关闭。
客服侧提供一键查询入口，能快速输出结论与失败原因，减少人工扯皮。

Step 5：退款与冲正

如果你的业务存在退款场景，建议提前明确退款口径、是否支持部分退款、退款状态查询与对账字段。上线后再补，往往会牵连财务与客服体系，成本很高。

四、代付 Pay-out 接入流程：出款要可控、可追踪、可审计

Step 1：提交代付请求，建议先做风控分层

代付比代收更需要风控。建议按用户等级、历史行为、金额区间做分层策略；对异常行为可采取延迟审核、分批出款或补充验证，避免出一次就追不回。

Step 2：状态追踪，必须可查询、可回调

payout_order_no：代付订单号，全局唯一，可追溯。
通道单号与状态：每笔代付都要能查询最终状态。
失败原因分类：失败必须可定位，便于客服解释与用户引导。
重试规则：哪些失败可自动重试，哪些需要人工介入，要提前定义，避免重复出款。

Step 3：代付对账，避免资金口径混乱

代付对账建议与代收统一口径与字段体系：同一套状态定义、同一套时间口径、同一套费用口径。否则财务与运营一定会各说各话，最后靠人工补洞。

五、对账与结算：把口径一次定清楚，后期省大量人力

建议至少包含以下对账字段，代收与代付尽量一致：

商户订单号、通道订单号
订单金额、手续费、结算金额
订单状态、失败原因
支付完成时间、入账时间、结算时间

强烈建议：在系统内明确区分以下三种状态：

支付成功：用户侧已完成付款。
入账成功：你的业务侧已完成记账与发货或加点动作。
可结算成功：资金进入可用或可结算口径，受结算规则与风控影响。

把三者混在一起，会直接导致财务对不上、客服解释不清、现金流误判。

六、更快结算策略：D0、同日结算等，商户应该问清什么

更快结算策略不是无条件秒到。更准确的理解是：在满足业务与风控评估的前提下，让资金更早进入可用状态。

结算条件：业务类型、交易质量、异常率等与结算策略的关系。
结算口径：什么状态算可结算，异常单如何处理，冻结与解冻规则是什么。
可预期性：规则透明、节奏稳定，便于预测现金流与备付金安排。

七、上线验收清单

回调验签：签名错误是否能被拒绝，关键字段是否纳入校验。
金额一致性：回调金额与下单金额不一致是否能拦截并告警。
幂等：重复回调是否只处理一次，是否有处理流水可追溯。
查询兜底：回调延迟时，订单是否能自动收敛到最终态。
失败原因：是否能分类输出，便于客服解释与运营优化。
对账字段：订单号、通道单号、手续费、结算金额、状态是否齐全可核对。
灰度放量：是否先小流量验证，再逐步全量。

八、常见问题处理

1）用户说已付款，但系统没有到账

先查订单是否收到回调；如未收到，走订单查询兜底收敛状态。
如查询为成功但未入账，检查幂等、落库逻辑与金额校验日志。

2）出现重复入账或重复发货

检查回调幂等：同一订单是否存在多次成功处理记录。
确保业务动作只在落库成功且状态从非成功变更为成功时触发。

3）代付出款失败或长时间处理中

通过通道单号查询代付状态与失败原因分类。
按规则决定自动重试或人工介入，避免重复出款风险。

九、联系币付对接开通

如需在菲律宾通过 GCash 接入代收代付服务，建议你提前准备以下信息，以便更快评估与开通：

业务类型、预计日/月订单量、单笔金额区间、峰值并发
是否需要代付、代付出款场景与风控要求
notify_url 回调域名与技术对接人联系方式

客服 Telegram：telegram:@Bifuapp
客服邮箱：[email protected]

安全提示：请勿相信任何非官方渠道散布的客服账号、钱包地址、收款二维码。对接与开通信息以以上官方渠道确认为准。