菲律宾游戏行业代收代付怎么设计?充值代收与结算代付为什么要走两套资金路径
游戏公司的两笔钱,方向完全相反
做菲律宾游戏业务的商户,账上同时存在两种性质不同的资金流水。一种是玩家充值,方向是"收",钱从玩家的钱包或银行账户流进商户账户,典型场景是手游内购、端游点卡、正规游戏平台的虚拟币充值。另一种是对外结算,方向是"付",钱从商户账户流出,对象是推广达人、渠道代理、供应商,偶尔还包括给玩家的退款。
很多刚接入本地支付的团队,第一版系统图省事,用同一套商户号、风控规则、对账逻辑处理这两类资金。短期能跑通,做大一点就容易出两类问题:一是代付端的异常提现容易触发原本给代收设计的反欺诈规则,风控规则互相打架;二是代付一旦被银行或通道方问询,商户很难在"收付不分"的账本里把"玩家消费充值"和"对外商业结算"这两类不同性质的资金解释清楚,反而拖累整体账户稳定性。
这里先说清楚一个边界:本文讨论的游戏行业代收代付,服务对象是合法经营的游戏公司——手游内购、端游点卡、云游戏订阅、正规平台虚拟道具与虚拟币充值,资金性质是消费类小额支付。它和博彩、赌博类资金收付是两套监管逻辑、两套风控标准,不能混为一谈,后面合规部分会展开讲。
代收链路与代付链路:玩家充值和达人结算分别怎么设计
代收这一侧,核心诉求是让充值路径顺畅,同时把异常交易挡在外面。菲律宾本地主流做法是把 GCash 原生直连、QRPH 聚合扫码、Maya 收款并列做成充值入口,玩家选自己习惯的钱包支付,商户后台统一归集。手游这类高频小额场景通常用动态码配合下单接口,一笔订单对应一个收款凭证,方便按订单核销;端游点卡、大额道具这类单笔金额更高的场景,则要在下单环节加更严的设备指纹和行为校验。
我们在 手游端游充值场景细分 里拆过手游 IAP、端游月卡、云游戏订阅这几类场景各自的通道选型差异,逻辑是一致的:充值入口越统一,后端对账越简单,但不同游戏品类的风控阈值不能用一套参数。如果一个商户同时做手游和端游分发,建议在同一套代收网关下按产品线拆出不同的风控策略组,而不是整站共用一组限额和规则。
代收链路本质上要解决的是"怎么让真实玩家的钱顺利进来、把盗卡盗号的钱挡在外面",游戏行业的整体接入思路可以参考 游戏支付整体接入方案,里面把充值代收和出款代付两端的接入顺序讲得比较完整。
代付这一侧服务的对象完全不同。游戏公司需要定期给推广达人结算佣金,给渠道代理分成,给内容供应商付款,偶尔还要处理玩家退款。这类资金的特点是:单笔金额通常比单笔充值更大,收款人是相对固定的一批主体(达人、代理、供应商),频率是周期性的(月结、周结),而不是玩家充值那种随时随地的高频小额。
技术路径上,代付一般走 InstaPay 或 PesoNet 这类银行间清算通道做批量代发,一次提交一批收款记录,系统按文件逐条处理并回传结果。最容易踩坑的是文件格式校验、单批次限额控制和失败重试策略,这部分可以参考 批量代付实操,这里不重复展开。
代付链路的风控重点和代收不同:代收防的是盗卡盗号、拒付纠纷,代付防的是账户信息不一致、收款人身份与声称身份不符、短期内异常集中提现这类洗钱风险特征。给达人结算之前,系统需要核实收款账户姓名和登记身份是否一致,这是代付侧独有的检查项。
两条链路为什么要在系统设计上物理分离
把代收和代付分开,不只是分两个团队处理,更关键的是在系统架构层面做物理或逻辑隔离,原因有三个。
第一,账户体系要分。代收资金归集到一个资金池,代付从另一个资金池出账,中间通过内部清算账户做资金调拨,而不是共用同一个商户余额。一旦某笔代付出现异常,排查范围只影响代付资金池,不会连带卡住玩家充值通道。
第二,密钥和权限要分。代收 API 只需要下单、查询、回调三个权限,不应拥有发起代付的权限;代付接口单独发一套密钥,建议加二级审批,较大批次需第二个管理员确认,代收下单不需要这道审批,否则会拖慢充值体验。
第三,风控策略要分。代收的风控模型看设备、IP、历史充值行为这些"买方画像"特征;代付的风控模型看收款账户身份一致性、资金集中度这些"卖方画像"特征。两套模型混在一起调参数容易互相冲突——调紧了代收规则,代付的正常批量结算也被误拦;调松了代付规则,又会把代收端该挡的异常交易漏过去。
技术怎么实现:两套密钥、两套回调、两套对账文件
落到代码层面,代收代付分离最直观的体现是两套独立的接口命名空间、密钥和回调地址。代收下单一般是这样的请求结构:
curl -X POST https://apix.smartpay.example/api/v1/collection/create \
-H "Content-Type: application/json" \
-d '{
"merid": "GAME100288",
"tno": "RECHARGE20261003001",
"amt": "1500.00",
"channel": "gcash_native",
"notify_url": "https://game.example.com/notify/collection",
"sign": "A1B2C3D4E5F6..."
}'注意这里的 notify_url 专门指向代收回调地址,和代付的回调地址必须是两个不同的端点,接收到异步通知后分别落到两张不同的流水表里,后续对账才不会混在一起。代付侧的批量结算请求结构不一样,通常是提交一个包含多条记录的数组,示例用 Node.js 演示请求和验签:
const crypto = require('crypto');
function signPayload(payload, apiSecret) {
const sorted = Object.keys(payload).sort()
.map(k => `${k}=${payload[k]}`).join('&');
return crypto.createHmac('sha256', apiSecret)
.update(sorted).digest('hex');
}
const payoutBatch = {
merid: 'GAME100288',
batch_no: 'PAYOUT20261003A',
channel: 'instapay',
items: [
{ payee_name: 'Juan Dela Cruz', account_no: '0912xxxxxxx', amt: '8500.00', memo: 'KOL202609' },
{ payee_name: 'Maria Santos', account_no: '0917xxxxxxx', amt: '6200.00', memo: 'AGENT202609' }
]
};
payoutBatch.sign = signPayload(
{ merid: payoutBatch.merid, batch_no: payoutBatch.batch_no, channel: payoutBatch.channel },
process.env.PAYOUT_API_SECRET
);
// 提交到代付专用端点,与代收 /collection/create 完全分离
// POST https://apix.smartpay.example/api/v1/payout/batch可以看到两段代码用的接口路径、密钥变量、业务字段都是独立的一套,这是代收代付分离在代码里最直接的表现。
对账怎么做:代收代付分开后怎么让两边都对得上
系统拆成两条链路后,对账也要跟着拆成两套逻辑,再用一张汇总表把两边的净流水勾在一起,否则财务很容易两头都对不上。
| 对账维度 | 代收侧(玩家充值) | 代付侧(达人/代理/供应商结算) |
|---|---|---|
| 核对对象 | 订单号 vs 通道回调流水 | 批次号 vs 银行/钱包出账明细 |
| 核对频率 | 按日实时流水核对 | 按批次(周结/月结)核对 |
| 常见差异类型 | 重复回调、金额尾差、超时未到账 | 部分记录失败、账户信息不符、批次重复提交 |
| 差异处理方式 | 自动重试查询通道状态 | 人工复核 + 失败记录重新提交 |
| 谁来看这份对账 | 运营/客服优先关注 | 财务/风控优先关注 |
实际操作中,建议每天先分别产出代收对账单和代付对账单,确认两边各自没有差异,再在次日生成一张合并的"资金路径"视图,把玩家充值总额、对外结算总额、资金池净额三个数字放在一起看。这个视图怎么画,可以参考 代收代付资金路径图解;商户后台想做得更自动化,也可以参考 商户对账方案对比 里手工、半自动、全自动三种方案的取舍。
合规边界:游戏支付不是博彩支付
游戏行业的代收代付经常被误解成和博彩支付是一回事,这里必须明确区分。本文讨论的场景,收款方是正规游戏公司的充值账户,付款对象是推广达人、分销代理、技术供应商,资金用途是手游内购、端游点卡、云游戏订阅、正规平台虚拟道具消费——这是消费型支付业务,不涉及投注、押注类博彩资金流转。两者的监管口径、牌照要求、风控标准完全不同,游戏支付走的是电子支付清算框架,博彩资金受独立且更严格的监管体系约束,两套业务不能走同一条通道。
做这类业务的第一道门槛是确认支付服务商本身持有合法牌照。BSP(菲律宾央行)的 OPS(运营支付系统牌照)和 EMI(电子货币机构牌照)是判断一家支付服务商是否合规的核心依据,接入前应该向服务商索要牌照信息并在 BSP 官网核实,而不是只看对方网站上的宣传文案。
选服务商除了看通道覆盖和接口友好度,更要确认对方能不能讲清楚持牌主体是谁、资金是否经过持牌机构的账户体系。
持有 BSP OPS/EMI 牌照的支付机构,在资金的收付路径、客户身份识别、异常交易报送这几个环节都要满足央行的合规要求,这也是游戏公司在合规层面唯一应该依赖的判断标准,而不是通道数量或者报价。
合规团队在准入审查时,也应要求商户承诺业务范围不涉及博彩、投注类产品,服务商有责任在签约环节核实商户的业务性质,而不是来者不拒。
通道怎么选:代收代付两端的技术路径对比
最后落到选型,代收和代付经常用到同一批通道名字,但承担的角色不一样,列一张对比表方便商户判断在哪个环节用哪个通道更合适。
| 通道 | 代收能力 | 代付能力 | 更适合的环节 |
|---|---|---|---|
| GCash 原生直连 | 强,支持下单直连不跳转 | 有限,个人侧受限额约束 | 玩家充值首选入口 |
| QRPH 聚合扫码 | 强,一码兼容多家钱包 | 不涉及 | 线下场景或多钱包玩家覆盖 |
| Maya 收款 | 中,作为并列充值入口 | 有限 | 玩家充值补充入口 |
| InstaPay | 不涉及 | 强,支持实时到账银行间转账 | 达人/代理单笔或小批量结算 |
| PesoNet | 不涉及 | 强,支持大批量文件代发 | 月结/周结的批量工资与佣金代发 |
可以看出,代收侧主要是钱包类通道在承担,代付侧则靠银行间清算通道。这也印证了前面的架构判断:代收和代付的底层通道本就不是同一批,没有理由揉进同一套逻辑。
常见问题
游戏公司的代收和代付一定要用两个商户号吗?
不是必须用两个完全独立的商户主体,但建议在同一主体下拆成两套子账户或两套 API 密钥,让权限、风控策略、对账流水各自独立,既统一财务主体,又不会出现前面提到的风控规则打架问题。
达人结算的钱可以走代收通道里的 GCash 原生直连吗?
技术上部分钱包类通道也能做小额转账,但不建议把达人结算走代收的充值通道,因为两类通道的限额设计、身份核验深度、失败处理流程是按不同场景设计的,硬凑在一起容易在限额或审核环节卡住,也不利于后续按"代收/代付"分类做合规报送。
怎么判断一家支付服务商是不是真的持牌?
直接向服务商索要 BSP 颁发的 OPS 或 EMI 牌照编号,再到 BSP 官网的持牌机构名单核实编号和主体名称是否一致,不要只看对方官网或宣传材料的文字描述。
手游内购和端游点卡的代收设计有区别吗?
有。手游内购是高频小额,适合用动态码配合下单接口自动核销;端游点卡单笔金额相对更高,建议在下单环节加更严格的设备指纹和历史行为校验,两类场景不建议套用同一组风控阈值。
批量代付失败了一部分记录,整批都要重新提交吗?
不需要。规范的批量代付接口按单条记录返回处理结果,只针对失败记录重新提交即可,具体文件格式和重试字段可以参考批量代付的实操说明。
游戏公司接入代收代付,需要额外证明自己不做博彩业务吗?
正规支付服务商在签约审查阶段通常会要求说明业务性质、提供游戏产品或平台的相关材料,这是服务商履行合规义务的一部分,也是把游戏消费支付和博彩资金流转在源头上区分开。
如果你的游戏业务正在设计充值代收和达人代付两条链路,想找一家持有 BSP OPS/EMI 牌照、能把架构讲清楚的服务商对接,可以联系我们。Telegram 咨询 @LouisSMARTPAY,或发邮件到 [email protected],按你的游戏品类(手游/端游/平台虚拟币)具体过一遍代收代付两端的技术方案。