Tarspay 菲律宾支付接入方案：GCash 原生收款与代收代付的技术链路、风控与对账要点（币付）

Tarspay 通道用于在菲律宾市场接入 GCash 原生支付，并可扩展到代收代付能力。把它做“能用”不难，难的是把它做成“稳定可控、可对账、可扩展、可风控”。本文从真实落地的工程视角，把关键点一次讲透，便于商户与技术团队按标准流程推进上线。

一、适用场景与能力边界

Tarspay 通道常见适用场景如下：

本地或跨境商户收款：面向菲律宾用户完成充值、购买、订阅等支付闭环。
平台型业务：需要代收与结算能力，先把资金流跑通，再逐步做精细化分账与结算策略。
代付场景：向用户或合作方打款，用于退款补偿、佣金结算、服务费结算等。

边界必须提前说清：额度、风控要求、结算周期、退款规则、异常处理时效等，以渠道与服务商的实际准入与风控规则为准。产品侧不要写“秒到、永不掉单、百分百成功率”这类承诺，后期只会放大纠纷与成本。

二、对接前必须准备的三件事

1）业务与合规资料

商户主体信息：公司或个人信息、注册地址、受益人信息等（按准入要求提供）。
业务说明：资金来源与去向、交易类型、退款政策、用户协议与隐私政策。
风控策略：高风险品类与地区策略、黑名单与限额策略、异常订单处置流程。

2）系统架构

订单中心：至少具备支付单、代付单、退款单三类对象，每个对象必须有唯一业务单号。
回调处理服务：独立模块处理异步通知，不要把回调逻辑塞进页面接口里。
对账与清分模块：哪怕先做最简版，也必须支持查询与导出每笔交易的状态变更与证据链。

3）上线验收标准

幂等：同一笔回调或查询重复到达，结果一致且不重复入账。
可观测：至少具备日志、指标、告警，能在分钟级发现成功率与延迟异常。
可回滚：支付入口、代付入口、回调入口都有降级策略，必要时可暂停新单与代付发起。

三、收款链路的标准实现要点

1）建议的核心状态机

INIT：已创建支付单，未发起渠道请求。
PENDING：已发起渠道请求，等待用户完成支付或等待回调。
SUCCESS：渠道确认成功，以回调或查询确认为准。
FAILED：明确失败，例如余额不足、风控拒绝、超时关闭等。
CLOSED：订单过期或主动关闭。

2）推荐交易流程：以异步为准

服务端创建订单，生成 merchant_order_id，写入订单中心，状态为 INIT。
服务端向 Tarspay 发起支付，返回支付参数或跳转链接，状态改为 PENDING。
用户在 GCash 完成支付。
回调到达后完成验签、落库、推进状态为 SUCCESS 或 FAILED。
业务侧发货或入账只认“已落库的 SUCCESS”，不要只看前端返回。

关键原则：支付是否成功，以回调与落库为核心证据；查询接口用于补偿，不用于替代回调。

3）签名与验签

所有关键回调必须验签，包含签名算法、密钥管理、时间戳窗口与 nonce 防重放。
验签失败直接拒绝处理，避免脏数据落库导致后续对账失真。
测试与生产密钥严格隔离，防止环境混用引发不可定位问题。

4）幂等与重复通知处理

以 merchant_order_id 作为幂等键；若渠道返回 channel_txn_id，也应建立唯一映射与唯一索引。
同一订单多次回调只允许“状态前进”，不允许成功变失败。
每次状态变更记录来源、原状态、新状态、回调摘要、处理耗时，便于追溯。

四、代付链路落地要点

1）代付风控通常更严

代付常见翻车点包括风控拦截、收款信息错误、重复代付、网络超时导致状态不一致。原则是把“可控”放在“速度”前面。

2）建议代付流程

创建代付单，生成 payout_order_id，记录收款方信息、金额、用途，状态为 INIT。
预风控校验，命中黑名单、超额、异常账户直接拒绝，避免把压力推给渠道。
发起代付到 Tarspay，状态改为 PENDING。
接收代付回调并验签，推进状态为 SUCCESS 或 FAILED。
对长时间 PENDING 的单做定时补偿查询，避免资金悬挂。

3）防重复与失败重试规则

同一业务事件只允许发起一次代付，例如提现申请 ID 只能对应一个代付单。
失败重试建议使用“新单号 + 原单关联”的策略，避免渠道侧判定重复。
任何自动重试都要设置上限与冷却时间，避免批量放大事故。

五、对账与资金管理：决定能不能规模化

1）最少做到三单一致

业务订单：你系统里的充值、购买、订阅记录。
支付订单：Tarspay 与渠道侧的交易记录。
资金流水：入账、手续费、退款、代付、冲正等资金变动。

任何时候都要能回答：这笔钱从哪来、到哪去、为什么变成这个状态、差额在哪里。

2）对账策略建议

日常对账：按约定周期拉取交易清单，与本地订单逐笔核对。
异常标记：自动识别渠道有单本地无单、本地成功渠道失败、金额不一致、状态不一致等。
差错处理：工单化处理，明确负责人、时效与补单或冲正策略。

六、稳定性与可运维：别等出事才补课

回调可用性：回调接口需高可用，超时会导致重复通知甚至触发风控异常。
超时与重试：支付发起、查询、代付都要设置超时；网络失败可重试，业务失败不要盲目重试。
监控指标：成功率、回调延迟分位数、PENDING 堆积量、失败原因分布、代付失败率与失败码分布。
降级策略：渠道波动时优先保障订单一致性与查询确认，必要时暂停新单或暂停代付。

七、实施费率：GCash 与 QRPH

以下为币付已配置的费率展示组件，包含 GCash 与 QRPH 的实施费率：

[rate-table type="all"]

八、上线前验收清单

支付与代付状态机完整，状态推进规则严格且可追溯。
回调验签、幂等、防重放全部通过压测与异常测试。
补偿查询机制已上线，定时扫描 PENDING 并自动纠偏。
对账导出与查询可用，能定位每笔订单的证据链与差异原因。
告警已接入，成功率、回调延迟、堆积量异常可在分钟级发现。

九、常见问题

1）用户支付了，但我这边没到账，通常是什么原因

常见原因包括回调未到、验签失败、回调处理报错导致未落库、系统只信前端结果。建议排查顺序是先查本地日志与回调入站记录，再做渠道查询补偿。

2）代付为什么经常失败

常见原因是收款信息不匹配、风控拦截、额度限制、重复提交。建议把失败码做分类统计，针对性优化资料校验与预风控。

3）能不能只用查询，不用回调

不建议。查询是补偿手段，不是主链路。只靠查询会放大系统成本、延迟与漏单风险。

十、币付对接支持

如果你希望更快落地 Tarspay + GCash 原生收款与代收代付能力，并把幂等、回调、对账、风控与上线验收一次做到位，可以联系币付获取对接建议与技术支持。

Telegram：@Bifuapp
邮箱：[email protected]