菲律宾批量出款 API 指南
创建订单只是开始；最终状态、异常保护和逐笔对账共同决定一笔出款能否安全完成。
- Payout API
- 批量出款
- 对账
一笔批量出款订单如何走到终态
请求字段边界：以正式接口文档为唯一依据
回调验签、幂等与主动查询
把所有回调视为未验证输入：保留原始报文，严格按正式规范校验签名、时间窗口与防重放字段；验签通过后仍要做订单级和事件级幂等。具体算法、字段拼接与密钥版本必须来自实际获发的接口文档。
先验签再改状态
在解析为业务事件前保留规范要求的原始内容，拒绝错误签名、过期时间戳和不受支持的签名版本。
重复和乱序都要幂等
同一事件可重复投递；用事件标识和商户订单号去重，只允许合法状态迁移，终态不能被更早的 pending 覆盖。
查询是补偿，不是重复付款
回调延迟、丢失或相互冲突时主动查询原订单；仅在确认最终状态后更新账本或决定是否创建关联重试单。
pending、failed 与 unknown 的处置边界
对账与安全重试：先确认旧订单，再决定新订单
每日按商户订单号、平台订单号、批次号、金额、币种、脱敏收款标识、最终状态、原因码及完成时间逐笔比对本地账本、回调记录、查询结果和实际可用的结算记录。账差先进入异常队列；只有原订单被明确判定为最终失败、失败原因允许重试且幂等边界清楚时，才创建与原单关联的新订单。pending 或 unknown 订单禁止盲目重试，回调成功也不能替代日终对账。
上线前必须跑通的测试用例
- 正常成功与重复提交
- 错误签名、过期时间戳与重放
- 重复回调与回调乱序
- 请求超时但订单已受理
- pending 长时间未终态
- failed 可重试与不可重试原因
- unknown 查询补偿与人工冻结
- 批次部分成功、部分失败
- 日终账差与重复付款告警
- 密钥轮换、限流和回滚预案
从联调到受控上线
- 01
验证签名、重放防护与重复回调
- 02
覆盖 success、pending、failed、unknown
- 03
小额受控上线并完成日终对账
服务边界：本页提供菲律宾批量出款 API 的通用接入方法与咨询说明，不代表 Bifu 是持牌资金机构，也不代表与 GCash、InstaPay、银行或其他品牌存在官方合作。实际可用的支付方式、字段、额度、费率、处理时效、结算安排及接口权限以当前通道和正式协议为准；资金处理、账户服务与相关合规职责由实际持牌或合作机构及签约主体按照适用规则负责。本页不构成成功率、到账速度或固定结算周期承诺。
常见问题
Payout API 和收款 API 有什么不同？
Payout 是平台向指定钱包或银行路径发起付款，重点是收款标识校验、防重复出款、异步终态与资金对账；收款 API 的付款发起方和订单流程不同，不能共用同一套状态处理。
接入时要提交哪些字段？
通常需要商户订单号、金额、币种、收款路径及该路径要求的收款标识，但字段名、格式、精度和必填范围必须以实际获发的正式接口文档为准，页面不会虚构固定参数。
接口返回 accepted 或平台订单号，是否表示已经到账？
不是。它通常只表示请求被接收。应等待经验证的最终回调或主动查询结果，再登记成功；具体状态含义以正式状态表为准。
同一回调重复发送应该怎么处理？
每次先按正式规范验签，再按事件标识和商户订单号幂等处理。相同终态重复到达应返回规范要求的确认响应，但不能重复记账、重复通知或再次触发业务权益。
pending 状态多久会完成？
页面不承诺固定完成时间。系统应按正式查询间隔退避轮询并设置内部告警阈值；超过阈值可转人工关注，但在明确终态前不能重复付款。
请求超时或状态 unknown 可以直接重试吗？
不能盲目重付。超时可能发生在订单已受理之后，应先用原商户订单号或平台订单号查询并核对；仍无法确认时冻结同一业务请求并进入人工复核。
failed 订单什么时候可以重试？
先确认它是最终失败，再根据正式原因码判断是否可重试。允许重试时使用规范要求的幂等方式；如需新订单号，应关联原订单并限制自动重试次数。
批量任务只核对批次总额可以吗？
不够。批次可能部分成功、部分失败或仍在处理中，必须逐笔核对订单号、金额、币种、收款标识、状态和原因码，再汇总批次结果。
目前支持哪些出款方式、额度和结算周期？
实际能力会随通道、账户、业务场景和适用规则变化，可直接查看当前可用的支付方式、接口权限、额度、费率、处理时效与结算安排；页面不作固定承诺。
Bifu 在出款流程中提供什么服务？
本页用于说明通用接入方法和咨询范围，不代表 Bifu 是持牌资金机构或任何支付品牌的官方合作方。具体服务以当前咨询结果为准；实际资金处理由实际持牌或合作机构及签约主体负责。
相关页面