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.
{
"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.
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.
Receive notifications#
Crypto callbacks contain event_id, event, and transaction. Verify signatures using the shared HMAC contract 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.