Recebendo o depósito
O que a BlendFi faz quando o USDT chega ao endereço de depósito. Caminhos exato, parcial e excedente.
Após o aceite, a BlendFi observa o endereço de depósito on-chain. A cada confirmação válida, a plataforma atualiza received_amount na conversão e decide a próxima transição com base no valor e na janela.
Os três caminhos
1. Valor exato dentro da janela → funded → liquidação automática
O caminho feliz. O cliente final transfere exatamente expected_source_amount antes de deposit_window_expires_at. A conversão transita para funded, a liquidação do Pix avança automaticamente, e a conversão termina em completed. Você recebe conversion.completed.
Você não precisa chamar nada. A liquidação é totalmente automática a partir de funded.
2. Valor abaixo do esperado → standby imediato
Qualquer depósito com received_amount < expected_source_amount leva a conversão para standby com standby_reason='under_funded', sem esperar a janela expirar. A política é: qualquer divergência é uma decisão sua, não um erro a ser tolerado em silêncio.
Você recebe conversion.standby. Decida entre liquidar pelo valor recebido (POST /v1/conversions/:id/liquidate) ou tratar caso a caso. Veja Standby e liquidação manual.
3. Valor acima do esperado → standby imediato
Análogo ao caso 2, com standby_reason='over_funded'. A conversão transita para standby no instante do depósito; você decide o desfecho.
Sub-caso: janela expirou com depósito presente
Se a janela expira (deposit_window_expires_at no passado) com received_amount > 0 mas ainda em awaiting_deposit, a conversão transita para standby com standby_reason='window_expired'. O cenário cobre depósitos atrasados que chegam após o prazo de 15 minutos.
Sub-caso: janela expirou sem depósito
Se a janela expira com received_amount = 0, a conversão transita para expired (terminal), a reserva é liberada, o lock é solto. Não há depósito para tratar.
Depósitos tardios em conversão já em standby
Se um depósito on-chain confirma após a conversão já estar em standby, ele é creditado em received_amount, mas a conversão não sai de standby automaticamente. A saída só acontece via /liquidate ou via expiração para abandoned.
Webhooks que você recebe
| Cenário | Webhook |
|---|---|
| Valor exato + janela liquida | conversion.completed |
| Valor exato + janela falha na liquidação | conversion.failed |
| Valor divergente (qualquer tipo) | conversion.standby |
| Janela expirada com depósito | conversion.standby |
| Janela expirada sem depósito | (sem webhook dedicado; a conversão fica em expired) |
A semântica completa de webhooks vai na seção de Webhooks quando o catálogo de eventos conversion.* for publicado.
Não recomende ao cliente final ajustar o valor
A UX correta é mostrar expected_source_amount ao cliente final e exigir o valor exato. Trate divergência como exceção, não como contrato. Cliente final que tenta "completar" um depósito parcial com um segundo depósito acaba causando duas confirmações, ambas em standby (a primeira) ou ignoradas (sem promoção automática a partir de standby).
Próximo passo
- Standby e liquidação manual: o caminho que cobre todas as divergências.