Pular para o conteúdo principal

Visão Geral de Status

Um pagamento passa por várias fases desde a criação até a liquidação final. Cada fase tem três status — Pendente, Em Processamento e Concluído — oferecendo visibilidade granular em cada etapa do pipeline.

Fluxo de Status

Durante a fase de Cash In, FAILED e ERROR são status terminais — nenhum fundo foi coletado, portanto nenhum reembolso é emitido. Para todas as fases seguintes (KYT Out, Cash Out), FAILED e ERROR são transitórios: o pagamento segue para o fluxo de reembolso (REFUND_PENDINGREFUND_PROCESSINGREFUNDED). REJECTED também aciona o fluxo de reembolso, pois ocorre apenas após o Cash In.

Descrição dos Status

Obter Status do Pagamento

Polling de Status

Use polling como fallback quando webhooks não estiverem disponíveis:
Use webhooks como método de notificação principal. Polling a cada 15–30 segundos é apropriado como backup.

Webhooks para Atualizações de Status

Assine o tipo de evento PAYOUT para receber notificações em tempo real a cada mudança de status:
Gerencie os eventos webhook de pagamento recebidos:

Boas Práticas

Sempre configure um endpoint webhook para eventos PAYOUT. Isso fornece atualizações instantâneas de status sem sobrecarga de polling e reduz chamadas desnecessárias à API.
Se a entrega do webhook falhar, consulte GET /api/v2/payouts/{id} a cada 15–30 segundos. Defina um timeout razoável (ex.: 5 minutos) e alerte sua equipe se um pagamento permanecer em qualquer estado de processamento por mais tempo que o esperado.
Cada status de falha tem uma causa distinta e a fase em que ocorre determina se haverá reembolso:
  • FAILED / ERROR durante Cash In — Terminal. Nenhum fundo foi coletado, portanto nenhum reembolso é emitido. Para ERROR, contate o suporte se persistir.
  • FAILED / ERROR após Cash In (KYT Out, Cash Out) — Transitório. Como os fundos já foram coletados, o pagamento segue automaticamente para REFUND_PENDINGREFUND_PROCESSINGREFUNDED.
  • REJECTED — Bloqueado por revisão de conformidade. Não retentar automaticamente; escalar internamente. Sempre aciona o fluxo de reembolso, pois os fundos já foram coletados.
  • REVIEW_NEEDED — Uma verificação KYT sinalizou a transação para revisão manual. O pagamento é retomado automaticamente ou passa para REJECTED; nenhuma ação necessária da sua parte.
Obtenha todos os pagamentos do dia anterior via GET /api/v2/payouts e reconcilie com seu livro-razão interno. Compare os status terminais esperados vs. reais para detectar discrepâncias antecipadamente.

Próximos Passos

Configurar Webhooks

Configure e proteja notificações webhook

Tratamento de Erros

Gerencie falhas da API com elegância