菲律宾支付接入实录：Skypay 与 Paynamics 代收代付链路设计及 GCash/QRPH 支付整合要点｜币付 Bifu

在菲律宾市场做支付，真正难点往往不在“能不能收款”，而在于资金链路是否可控、回调是否可靠、对账是否闭环、代付是否可审计。本文以 Skypay 与 Paynamics 的典型接入形态为例，拆解“代收 + 代付 + GCash/QRPH”一体化方案的关键设计点，帮助商户与平台在上线前把风险、成本与交付周期控制在可预期范围内。

一、业务范围与交付目标

本文面向以下角色：

电商、数字内容、订阅平台：需要本地化收款与稳定回调，降低支付失败与投诉率
SaaS 与聚合平台：需要多商户分账、统一对账、代付发放，用于佣金、退款、结算等场景
技术与财务团队：需要清晰的数据口径、可追溯的资金流水、可审计的风控策略

交付目标通常包含：

支持 GCash、QRPH 等主流本地渠道的收款能力，支付状态实时可追踪
代付能力可控：支持单笔与批量出款，出款结果可回执、可复核
对账闭环：交易单、支付单、清算单、余额变动一致，差错可定位
风控合规前置：身份与交易合规要求在设计阶段完成，避免上线后被动整改

二、参与方与资金链路

在“支付服务商 + 钱包/银行渠道 + 商户系统”的典型模型中，建议先把角色与账务边界画清楚：

商户系统：负责订单、商品或服务交付、用户账务、退款规则
支付服务商：如 Skypay 或 Paynamics，负责渠道接入、交易处理、结算与出款能力、回调通知
渠道侧：如 GCash/QRPH（也可扩展到 Maya（PayMaya）、GrabPay、Coins.ph 等），负责用户扣款与支付确认
清算与结算账户体系：决定资金归集、结算周期、手续费扣取、余额管理与出款来源

代收链路常见分两段：

订单侧：创建订单 → 创建支付请求 → 引导用户完成钱包支付 → 支付结果回传
账务侧：支付成功 → 入账记账 → 发货或开通服务 → 后续退款与冲正

代付链路的核心是“可审计与可回滚”：

出款申请单 → 风控审核 → 发起出款 → 回执落库 → 对账确认 → 用户到账通知

三、系统架构：把支付当成一套可运营的系统

建议将支付相关模块拆成可维护、可观测的组件，而不是散落在业务代码里：

支付编排层：统一创建支付、查询状态、发起退款、发起出款
回调与 Webhook 处理层：验签、幂等、状态机推进、异常告警
账本层：订单与资金流分离记录，支持审计与追责
对账引擎：按服务商账单与交易明细核对差异，生成差错单
风控引擎：黑名单、限额、频控、设备指纹、异常行为策略
运维观测：成功率、回调延迟、失败原因聚类、差错率与告警

四、代收接入要点：支付创建、回调可靠性与状态机

1）支付创建：参数与订单一致性

支付请求必须与订单强绑定，至少包含：

商户订单号：唯一且不可复用
支付单号：可与订单号相同或不同，但必须唯一
金额与币种：金额精度与四舍五入规则固定
用户标识：例如内部 userId 或外部 customerId
回调地址与前端跳转地址

建议在创建支付时就落库支付单，并将状态机初始化为 INIT。后续所有变化只允许由回调或主动查询推进，避免前端伪造成功。

2）回调与通知：验签、幂等、可重放

回调稳定性是上线成败关键。无论是 Skypay 还是 Paynamics，工程上建议：

验签必做：使用服务商提供的签名算法与密钥校验请求来源，未验签不得更新状态
幂等必做：同一笔支付可能多次通知，建议用“支付单号 + 事件号/时间戳/签名摘要”去重
状态机推进：仅允许 INIT → PENDING → SUCCESS/FAILED，已 SUCCESS 不允许回退
可重放：保存脱敏后的原始回调报文与验签结果，便于排障与审计

3）以最终一致为前提：主动查询兜底

回调可能延迟或丢失，建议设计查询兜底机制：

对 PENDING 状态按策略触发查询
以服务商侧订单状态为准推进本地状态
超过阈值仍不明确的支付单进入人工复核队列

五、代付接入要点：审批链、出款回执与资金安全

1）出款必须有业务单据与审批链

代付不是调用一个接口那么简单，至少应具备：

出款申请单：来自退款、佣金、结算、薪酬等业务
风控校验：收款人信息一致性、历史行为、限额、频次
审批流程：按金额与风险等级触发人工或多级审批

2）出款结果：不能只看请求成功

很多团队踩坑在于把“接口返回成功”当成“到账成功”。建议把出款拆成三层状态：

REQUEST_ACCEPTED：服务商接受请求，但未必处理完成
PROCESSING：处理中，等待最终结果
COMPLETED / REJECTED：最终完成或拒绝，必须落库原因码与原始回执

同时，出款同样需要验签回执、幂等保证、查询兜底与对账确认。

六、对账与清结算：让财务说得清、对得上、查得到

建议把对账当成上线前硬指标，否则规模上来后会被差错拖垮。

1）三本账：订单账、支付账、资金账

订单账：业务层面应收、已收、退款、争议
支付账：支付单状态、渠道信息、手续费明细、失败原因
资金账：余额变动、结算入账、出款出账、调账记录

2）差错处理：要有差错单与闭环动作

常见差错包括金额不一致、重复通知、重复出款、订单成功但支付失败、支付成功但未发货等。差错单建议包含：

差错类型、涉及单号、服务商侧流水、差额金额、原因码
处理人、处理结果、附件信息（如回调报文、截图等）

七、风控与合规：前置设计，避免支付能力被限制

在菲律宾市场接入本地钱包与代收代付，建议优先关注：

商户资料与 KYC：主体一致性、经营范围与交易场景描述必须匹配
AML 与异常交易：高频小额、异常地域、异常设备、短期突增等策略需可配置
数据安全：密钥分级管理、最小权限、敏感字段脱敏存储、访问审计
退款与争议：明确退款触发条件、退款路径、争议工单流程

八、上线与运维：把支付稳定性变成可量化指标

支付系统运维关键在于可观测。建议至少建立：

成功率监控：按渠道、地区、设备、版本拆分
回调延迟监控：通知到达时间分布，异常波动告警
失败原因聚类：把服务商原因码映射为可读分类
对账差错率：差错单数量、平均处理时长、可自动修复比例

九、常见问题与排障路径

问题：用户已扣款但订单未成功
处理：先查支付单是否收到回调 → 未收到则查回调日志与验签失败记录 → 触发查询兜底 → 若服务商显示成功则补偿推进订单并记录补偿原因。

问题：回调频繁重复导致重复发货
处理：检查幂等键设计 → 确保发货动作只允许由支付状态机从 PENDING 推进到 SUCCESS 的首次成功事件触发。

问题：出款重复
处理：业务单据必须唯一 → 出款接口必须幂等 → 出款前锁定业务单 → 出款回执与对账确认后再释放锁。

问题：对账对不上
处理：核对金额精度与手续费口径 → 核对是否存在部分退款或冲正 → 核对同一订单多次支付的合并逻辑 → 生成差错单推进闭环。

十、币付 Bifu 能提供什么

币付面向菲律宾支付场景，提供从方案设计到联调上线的全流程支持，重点解决：

Skypay 与 Paynamics 接入策略评估：代收、代付能力边界与落地路径梳理
支付系统工程化改造：回调幂等、状态机、账本与对账引擎的落地建议
风控与运营指标搭建：成功率、回调延迟、原因码体系与告警策略
上线后的稳定性治理：灰度策略、异常补偿、差错闭环与审计留痕

十一、币付 Bifu 实时费率表（含 GCash、QRPH 等）

[rate-table type="all"]

联系币付

Telegram：@Bifuapp
邮箱：[email protected]