GCash 原生支付：D0 结算与代收代付全流程指南（币付）

GCash 原生支付适合面向菲律宾用户的线上与线下收款场景：用户侧体验熟悉、转化链路短；商户侧只要把订单、回调、对账、结算体系做扎实，就能把“收款 + 出款 + D0 结算”串成一条可控的资金闭环。

本文从业务视角与技术视角同时出发，给出一套端到端落地指南：需要准备什么、接口怎么设计、回调如何防重、对账如何闭环，以及 D0 结算要满足哪些关键条件。并在文末给出“币付（Bifu）一站式接入”的落地建议。

实时费率（GCash & QRPH）

[rate-table type="all"]

一、先把概念讲清：原生支付、代收代付、D0 结算

1) GCash 原生支付是什么

“原生”通常包含两层含义：

用户侧原生：用户使用 GCash App 完成授权与支付，常见表现为跳转、唤起、二维码扫码等。
通道侧原生：支付状态、资金清算与结算数据由 GCash 体系产生，商户通过合规通道获取支付结果、对账数据与结算入账。

实际商业落地中，线上支付与批量代付往往需要通过具备资质与合作关系的服务商来完成对接与清结算管理；也有商户会同时评估 QRPH、Maya/PayMaya、GrabPay、Coins.ph 等本地方式，做更高覆盖与更稳成功率。

2) 代收与代付分别解决什么

代收：帮商户向用户收款，常见于订单支付、充值、订阅、缴费等。
代付：帮商户向用户或合作方出款，常见于退款、佣金、薪资、派奖、供应商结算等。

成熟方案必须把“支付成功”与“资金可用”区分开：支付成功不等于资金可自由划拨，资金可用取决于清结算节奏与风控规则。

3) D0 结算的价值与边界

D0 通常指交易发生当日完成结算入账或可用额度释放，价值在于：

提高资金周转效率，现金流更顺；
降低商户垫资压力，尤其适合高频小额或毛利较薄业务；
支持更灵活的代付：当日订单收入当日发佣金或返现。

关键提醒：D0 并非所有业务、所有风险等级、所有商户都天然具备。它通常需要更强的风控、备付/保证金安排，以及更严谨的对账与资金管理机制。

二、适用场景与方案选择：你应该做哪一种原生接入

1) 线下：门店与柜台收款

典型为收款码或顾客出示付款码。线下强调流程短、确认快、易培训、易对账。

优点：链路短、用户熟悉、转化高。
注意：明确付款确认依据，并建立异常处理流程：通知延迟、争议留痕、人工核验与补单机制。

2) 线上：网页、H5、APP 内支付

线上更依赖订单系统、回调系统、查询补单、对账系统。重点要解决：

支付完成后如何稳定拿到结果：回调 + 主动查询双保险；
如何防止重复通知导致重复发货或重复入账：幂等与状态机；
如何处理退款、关闭订单、超时取消与异常兜底。

3) 代付：批量出款与自动化出款

代付不是“把钱转出去”这么简单，应当当作一条独立交易流水来设计：

出款申请、审核开关、执行、回执、失败重试、对账与追踪；
收款方信息校验、黑名单与风控策略、限额与频控；
可观测性：每一笔出款都能查到“谁发起、何时执行、为什么失败、是否重试、最终落账”。

三、入驻与准备：决定你能否拿到 D0 的基础能力

1) 商户资料与合规准备

不同接入方式与风险等级，对资料要求不同。建议项目启动时一次性准备：

商户主体信息与真实经营信息，用于 KYB/KYC；
银行账户或结算账户信息，用于结算与对账；
业务模式说明：资金流向、退款规则、交付方式、争议处理；
风控与客服流程：异常交易处理、退款与争议处理、证据留存规则。

2) 系统侧必须补齐的“底盘”

订单体系：全局唯一商户订单号 merchant_order_id，严格的订单状态机；
回调体系：HTTPS 回调、签名验签、重复通知处理、失败重试承接；
查询补单：主动查询支付状态，作为回调丢失/延迟兜底；
对账体系：支持按通道单号与商户单号核对，形成日常对账闭环。

3) 做 D0 额外要补齐的能力

更强风控：黑名单、设备指纹、异常频次、异常金额、行为路径等策略；
资金保障：备付/保证金/分层额度，用于覆盖退款、争议或延迟确认风险；
更及时对账：D0 需要更快确认可用资金，对账必须及时且可追溯。

四、代收全流程：从创建订单到支付确认

步骤 1：创建订单

先在自有系统生成订单，必要时冻结库存或权益；不要在“未确认支付成功”前发货。

步骤 2：发起支付

向通道发起支付请求，获取支付凭证，常见为跳转链接、二维码内容或唤起参数。

{
  "merchant_order_id": "M2026XXXXXX",
  "amount": 19900,
  "currency": "PHP",
  "subject": "Order Payment",
  "notify_url": "https://yourdomain.com/pay/notify",
  "return_url": "https://yourdomain.com/pay/return",
  "customer": {
    "user_id": "U123",
    "email": "[email protected]"
  },
  "metadata": {
    "biz_scene": "topup_or_ecommerce",
    "ip": "user_ip",
    "device_id": "device_fingerprint"
  }
}

notify_url 用于后端回调，最终以它为准；return_url 只用于前端展示，不可作为支付成功依据。
建议携带 metadata：对风控、对账、客服排查非常关键。

步骤 3：用户完成支付

用户在 GCash App 内完成确认与鉴权，例如 OTP、MPIN、生物识别等，具体以通道与钱包规则为准。

步骤 4：回调通知（必须做对）

支付完成后，通道向 notify_url 推送结果。回调处理必须做到：

验签：只接受签名正确的数据；
幂等：同一订单多次通知只能处理一次；
状态机：只允许合法状态迁移（例如 CREATED → PAID → SETTLED）；
可观测：记录回调原文、验签结果、处理耗时、处理结果。

步骤 5：主动查询补单

回调可能因网络异常延迟或丢失。建议在以下情况触发查询：

用户返回页面显示处理中或未知；
超时未收到回调但用户声称已扣款；
回调验签失败或字段缺失。

五、结算与资金流：把 D0 讲透

1) 结算结构：别把“支付成功”当“资金可用”

环节	你要确认什么	对系统的要求
支付成功	交易完成，是否可发货或发放权益	回调验签、幂等、状态机
清分清算	手续费、通道成本、退款预留的计算	账务规则配置、对账
结算入账	资金进入结算账户或可用余额	结算流水对账、余额核对
资金可用	可用于代付、提现、再结算	额度、保证金、风控策略

2) D0 的常见落地方式

D0 的实现通常依赖“风控分层 + 资金保障 + 规则化释放”，常见做法包括：

分层结算：低风险订单快速释放，高风险订单延后释放或人工复核；
预留金/保证金：预留部分资金覆盖退款与争议风险；
额度机制：配置 D0 可用额度，额度用完则切换到常规结算节奏。

建议把 D0 当成可配置能力，而不是固定承诺。对外可描述为“支持更快的资金周转方案，以商户资质与风控结果为准”。

六、代付全流程：从出款申请到回执对账

步骤 1：代付申请

必须有全局唯一的 payout_id 或 merchant_payout_id；
建议支持审核开关：部分业务需要先审核再执行；
代付请求也要做签名与验签，防止被伪造。

步骤 2：收款信息校验

代付最怕错付。合规允许的前提下，建议做：

账户/钱包标识格式校验：长度、格式、黑名单；
如通道支持，可做姓名一致性或弱校验；
高风险账号拦截：历史拒付、欺诈、异常频次。

步骤 3：执行与回执

代付执行可能返回“处理中/成功/失败”等状态，同样需要回调验签与幂等；
失败原因要可枚举：可重试与不可重试必须区分；
代付作为独立流水纳入对账体系，确保能落到“可核对、可追踪、可补救”。

七、对账与风控：决定你能跑多大规模、D0 能开多大额度

1) 对账闭环

交易对账：按通道单号与商户单号核对成功金额、手续费、净额；
结算对账：核对结算入账流水与可用余额变化；
差错处理：建立差错单，覆盖重复回调、少回调、金额不一致、退款未到账等。

2) 风控要点（必须工程化）

幂等与防重：支付回调、退款回调、代付回调都必须防重；
限额与频控：按用户、设备、IP、商户维度做频次与金额限制；
异常拦截：短时间内多笔失败、异常大额、异常地域与设备切换；
争议预案：保留证据链（订单、交付、日志、用户信息），并明确合规边界。

八、常见问题：为什么接通了却跑不稳定

1) 支付成功但系统未发货

先看回调日志：是否收到、是否验签成功、是否被幂等拦截；
再做主动查询补单：以通道侧最终状态为准；
最后走人工排查：用商户单号、通道单号、金额、用户标识快速定位。

2) 重复回调导致重复发货或重复入账

这是系统设计问题，必须做到：

回调处理以 merchant_order_id 为主键上锁，或使用唯一索引约束；
只允许订单状态按既定路径迁移，非法状态直接拒绝处理；
把“发货/发权益/入账”都挂在同一套幂等逻辑下。

3) 想上 D0 但风控总卡

先从小额度与低风险场景开始，跑出稳定对账与低差错率；
逐步扩大额度与场景，持续降低退款率与争议率；
把关键指标工程化：成功率、回调到达率、对账差错率、退款率、异常率。

九、GCash / QRPH / Maya 等多通道怎么选

很多商户最终会走“多通道覆盖”的路径：GCash 原生 + QRPH 扫码（更广覆盖）+ 其他本地方式（如 Maya/PayMaya、Coins.ph、GrabPay 等），以提升成功率与支付转化。

只做单通道：接入快，但抗风险与覆盖有限；
多通道聚合：前期设计更严格，但长期更稳、更可控、更利于扩展（也更利于对账与结算统一）。

此外，市面上也有 PayerMax、Tarspay、SafePay、TQPay 等服务形态各异的方案，核心还是回到：成功率、结算节奏、对账透明度、风控能力、以及你能否做到“统一接口与统一账务”。

十、币付（Bifu）能为你做什么

币付（Bifu）聚焦菲律宾本地支付场景，为商户提供从代收、代付、对账结算、风控策略到 D0 资金周转方案的一体化接入支持。你只需要维护一套对接与订单体系，就能把支付能力稳定跑起来，并可按业务体量逐步升级结算与额度策略。

支持 GCash 原生支付与 QRPH 聚合扫码；
统一接口/统一回调/统一对账/统一结算/统一风控；
支持批量代付与自动化出款，便于佣金、退款、薪资、供应商结算等场景；
D0 可配置：按商户资质与风控分层动态释放，提高资金周转效率。

联系客服

Telegram：@Bifuapp
Email：[email protected]

说明：本文为通用流程与架构建议，具体接入细节、费率、限额、结算与风控规则以实际签约与通道侧配置为准。