状态概览
付款从创建到最终结算会经历多个阶段。每个阶段有三个状态——待处理、处理中和已完成——让您在整个流程的每个步骤都能获得精细的可见性。状态流转
状态说明
获取付款状态
轮询状态
当 webhooks 不可用时,使用轮询作为备选方案:通过 Webhooks 获取状态更新
订阅PAYOUT 事件类型,在每次状态变更时实时收到通知:
最佳实践
Webhooks 作为主要渠道
Webhooks 作为主要渠道
始终为
PAYOUT 事件配置 webhook 端点。这可以即时获取状态更新,无需轮询开销,并减少不必要的 API 调用。轮询作为备用方案
轮询作为备用方案
如果 webhook 交付失败,每 15–30 秒查询一次
GET /api/v2/payouts/{id}。设置合理的超时时间(例如 5 分钟),如果付款在任何处理状态停留时间超过预期,及时通知团队。区分失败状态
区分失败状态
每种失败状态都有不同的原因。
FAILED 或 ERROR 发生的阶段决定是否发起退款:- 收款阶段的
FAILED/ERROR— 终态。未收集到任何资金,不会发起退款。ERROR若持续出现请联系支持。 - 收款阶段之后的
FAILED/ERROR(KYT 出账、出款)— 过渡状态。由于资金已收集,付款自动转入REFUND_PENDING→REFUND_PROCESSING→REFUNDED。 REJECTED— 因合规审查被拦截。不可自动重试,应在内部升级处理。由于资金已收集,始终会触发退款流程。REVIEW_NEEDED— KYT 检查标记了该交易需要人工审查。审查完成后付款将自动恢复或转为REJECTED,您无需采取任何行动。
每日对账
每日对账
通过
GET /api/v2/payouts 获取前一天的所有付款,并与内部账本核对。比较预期与实际的终态,及早发现差异。下一步
配置 Webhooks
配置并保护 webhook 通知
错误处理
优雅地处理 API 错误