Modelo de status

​

Cash-in (domínio)

Além de PENDING, PAID, EXPIRED e FAILED, o sistema pode transitar por estados intermediários ou não conclusivos quando o retorno do parceiro não é imediato ou há falha de rede. Mapeamento CashIn (webhook de parceiro) → status interno de cash-in (documento de origem): Integração prática: trate PAID como sucesso de recebimento para liberar o pedido; monitore PENDING prolongado e estados não terminais (boas práticas).

​

Cash-out (domínio)

O fluxo completo envolve reserva, despacho e liquidação. Mapeamento CashOut (webhook de parceiro) → status interno (origem): A resposta imediata do POST pode refletir o estado no momento do commit (não necessariamente apenas a palavra PENDING).

​

Refund-in (domínio)

​

Terminalidade (orientação prática)

• Tendencialmente terminais de negócio: PAID, EXPIRED, FAILED (cash-in); CONFIRMED, FAILED, REVERSED (cash-out); CONFIRMED, FAILED (refund) — ajuste conforme a sua política de REVERSED e conciliação.
• Não trate como concluso: PROVIDER_RESULT_UNKNOWN e RECONCILIATION_REQUIRED (e pipeline intermediário de cash-out) — use consultas, webhooks e reconciliação.

​

Ver também

• Diagramas e sequências: Ciclo de vida
• Guia operacional: Reconciliar transações