# USDT overview

## A separate payment contract

USDT payments use the `/api/v1/merchant/crypto` API family and require merchant activation. Your existing INR endpoints and amount rules remain unchanged.

Authenticate with the same server-side merchant Bearer API key. Crypto amounts are decimal strings with no more than six fractional digits. Do not calculate USDT using floating-point arithmetic.

```json
{
  "amount": "200.000000",
  "address": "YOUR_VALID_TRON_RECIPIENT_ADDRESS"
}
```

The address above is a placeholder. Replace it with a validated TRON address in your integration.

## Receive payments

Create reusable customer addresses with a stable `customer_id`. Each received transfer has a distinct receipt ID, even when one customer sends the same amount twice.

Credit is based on the actual received amount and its recorded fee. A customer-supplied transaction hash is not proof of payment.

[Create customer addresses →](/crypto-addresses/)

## Understand availability

| State | Meaning |
| --- | --- |
| `pending_confirmation` | Awaiting the required confirmation process |
| `pending_collection` | Awaiting collection before funds become available |
| `available` | Funds are available under the wallet’s current restrictions |
| `frozen` | Funds are not spendable |
| `dust` / `orphaned` | Receipt is not spendable |

## Send payouts

Request a quote, review its amount and fee, then submit it with a stable idempotency key. One eligible wallet must cover the payout amount and fee; separate wallets cannot be combined to fund it.

[Create a USDT payout →](/crypto-payouts/)

## Receive notifications

Crypto callbacks contain `event_id`, `event`, and `transaction`. Verify signatures using the [shared HMAC contract](/webhooks/) and deduplicate by `event_id`. Deliveries can repeat; each attempt receives a fresh signature and timestamp.

When events arrive out of order or the outcome is unclear, query the original transaction status.