跳转到主要内容

状态概览

付款从创建到最终结算会经历多个阶段。每个阶段有三个状态——待处理、处理中和已完成——让您在整个流程的每个步骤都能获得精细的可见性。

状态流转

在**收款(Cash In)**阶段,FAILEDERROR 是终态——未收集到任何资金,因此不会发起退款。对于所有后续阶段(KYT 出账、出款),FAILEDERROR 是过渡状态:付款将转入退款流程(REFUND_PENDINGREFUND_PROCESSINGREFUNDED)。REJECTED 也会触发退款流程,因为它仅在收款阶段之后发生。

状态说明

获取付款状态

轮询状态

当 webhooks 不可用时,使用轮询作为备选方案:
优先使用 webhooks 作为主要通知方式。每 15–30 秒轮询一次适合作为备用方案。

通过 Webhooks 获取状态更新

订阅 PAYOUT 事件类型,在每次状态变更时实时收到通知:
处理收到的付款 webhook 事件:

最佳实践

始终为 PAYOUT 事件配置 webhook 端点。这可以即时获取状态更新,无需轮询开销,并减少不必要的 API 调用。
如果 webhook 交付失败,每 15–30 秒查询一次 GET /api/v2/payouts/{id}。设置合理的超时时间(例如 5 分钟),如果付款在任何处理状态停留时间超过预期,及时通知团队。
每种失败状态都有不同的原因。FAILEDERROR 发生的阶段决定是否发起退款:
  • 收款阶段的 FAILED / ERROR — 终态。未收集到任何资金,不会发起退款。ERROR 若持续出现请联系支持。
  • 收款阶段之后的 FAILED / ERROR(KYT 出账、出款)— 过渡状态。由于资金已收集,付款自动转入 REFUND_PENDINGREFUND_PROCESSINGREFUNDED
  • REJECTED — 因合规审查被拦截。不可自动重试,应在内部升级处理。由于资金已收集,始终会触发退款流程。
  • REVIEW_NEEDED — KYT 检查标记了该交易需要人工审查。审查完成后付款将自动恢复或转为 REJECTED,您无需采取任何行动。
通过 GET /api/v2/payouts 获取前一天的所有付款,并与内部账本核对。比较预期与实际的终态,及早发现差异。

下一步

配置 Webhooks

配置并保护 webhook 通知

错误处理

优雅地处理 API 错误