Check a Deposit

After the customer sends testnet USDT to the issued address, network confirmations and service processing may take time. Use the deposit APIs rather than balance changes alone to identify the transfer.

Discover external deposits

deposit_response="$(
  wallet_request GET "/deposits?account_id=$ACCOUNT_ID&type=EXTERNAL&after_id=0&limit=100"
)"
printf '%s\n' "$deposit_response" | jq

The cursor query requires type=EXTERNAL or type=INTERNAL. These types use different ID sequences and cannot share a cursor. This customer on-chain deposit uses EXTERNAL.

Save and advance the cursor

The response contains:

{
  "success": true,
  "data": {
    "items": [],
    "next_cursor": 123,
    "has_more": false
  },
  "error": null
}

Upsert every item by deposit_id, then save next_cursor. When has_more is true, immediately request the next batch. Where possible, persist the items and cursor in one database transaction.

Track a non-final deposit

An ID cursor returns newly created records, not later state changes. Poll every discovered non-final deposit by ID.

export DEPOSIT_ID='{deposit-id-from-list}'
wallet_request GET "/deposits/$DEPOSIT_ID?type=EXTERNAL" | jq

Stop polling after a final status. Credit the customer-facing deposit state only according to the authoritative API result; do not infer confirmation from an explorer or balance alone.

Use deposit status rather than requiring user_status. Track approval, verification, and refund stages as well as PENDING. Only COMPLETED confirms a successful customer deposit; REFUNDED and FAILED do not. See Status Codes for all states.

Next: Check balances and ledger.