Receiving the deposit
What BlendFi does when USDT arrives at the deposit address. Exact, partial, and overpayment paths.
After accept, BlendFi watches the on-chain deposit address. On every valid confirmation, the platform updates received_amount on the conversion and decides the next transition based on amount and window.
The three paths
1. Exact amount within window → funded → automatic settlement
The happy path. The end customer transfers exactly expected_source_amount before deposit_window_expires_at. The conversion transitions to funded, Pix settlement advances automatically, and the conversion ends in completed. You receive conversion.completed.
You do not need to call anything. Settlement is fully automatic from funded onward.
2. Amount below expected → immediate standby
Any deposit with received_amount < expected_source_amount takes the conversion to standby with standby_reason='under_funded', without waiting for the window to expire. The policy is deliberate: any divergence is your decision, not an error to be silently tolerated.
You receive conversion.standby. Decide between liquidating at the received amount (POST /v1/conversions/:id/liquidate) or handling case by case. See Standby and manual liquidation.
3. Amount above expected → immediate standby
Analogous to case 2, with standby_reason='over_funded'. The conversion transitions to standby at the moment of deposit; you decide the outcome.
Sub-case: window expired with deposit present
If the window expires (deposit_window_expires_at in the past) with received_amount > 0 but still in awaiting_deposit, the conversion transitions to standby with standby_reason='window_expired'. This covers late deposits that arrive after the 15-minute deadline.
Sub-case: window expired with no deposit
If the window expires with received_amount = 0, the conversion transitions to expired (terminal), the reserve is released, the lock is cleared. There is no deposit to handle.
Late deposits on a conversion already in standby
If an on-chain deposit confirms after the conversion is already in standby, it is credited to received_amount, but the conversion does not leave standby automatically. Exit only happens via /liquidate or via expiry to abandoned.
Webhooks you receive
| Scenario | Webhook |
|---|---|
| Exact amount + window settles | conversion.completed |
| Exact amount + window fails to settle | conversion.failed |
| Divergent amount (any kind) | conversion.standby |
| Window expired with deposit | conversion.standby |
| Window expired with no deposit | (no dedicated webhook; conversion sits in expired) |
The full webhook semantics land in the Webhooks section once the conversion.* event catalog is published.
Do not recommend that the end customer adjust the amount
The correct UX is to show expected_source_amount to the end customer and require the exact amount. Treat divergence as an exception, not as a contract. An end customer who tries to "complete" a partial deposit with a second deposit ends up causing two confirmations, both standby (the first) or ignored (no automatic promotion out of standby).
Next step
- Standby and manual liquidation: the path that covers all divergences.