Практические сценарии

Send USDT and USDC payouts with the API

Это содержимое пока не доступно на вашем языке.

Use this recipe to send a stablecoin payout from your CoinsSend merchant balance to an external wallet. A successful withdrawal request starts processing; it does not mean the recipient has already received the funds.

Your application controls who should be paid and records each payout’s business purpose. CoinsSend’s public withdrawal API takes the coin, network, amount, and destination address.

1. Check the recipient, network, and available funds

Enable Allow Withdrawals in the merchant dashboard and keep signing credentials on your backend.

Fetch GET /v1/coins-and-fee and GET /v1/get-coin-rate to choose a currently available coin/network pair and check operation flags, minimums, and precision. See supported coins and networks for the matching rules. Do not infer availability from the token symbol alone.

For example, USDC on Arbitrum One uses coin: "usdc" and network: "arbitrum"; USDT on TRON uses coin: "usdt" and network: "tron". Confirm that the recipient can receive the selected token on the exact selected network.

Read your merchant balances and fees before submitting. Static-wallet deposits have a hold, and the amount visible as a deposit is not necessarily available to withdraw yet.

2. Build the withdrawal request

Send a signed POST /v1/withdrawals with this JSON body shape:

{
  "network": "tron",
  "coin": "usdt",
  "amount": "50.75",
  "to_address": "RECIPIENT_ADDRESS_ON_THE_SELECTED_NETWORK"
}

Replace the destination placeholder with the intended recipient’s address. amount is a decimal string in the selected cryptocurrency, not USD. Choose an amount that satisfies the current limits and your available balance.

Withdrawals require a timestamped HMAC-SHA256 signature:

Content-Type: application/json
Merchant: YOUR_MERCHANT_ID
Timestamp: UNIX_TIME_IN_SECONDS
Sign: HMAC_SHA256(BASE64(CANONICAL_JSON_BODY) + "." + TIMESTAMP, API_KEY)

Use the canonical serialization in Authentication; arbitrary JSON formatting is not interchangeable. The timestamp must be within five minutes of server time. The Node.js withdrawal example shows the complete signing and submission flow.

The exact request and response fields are in the withdrawal reference.

3. Store the accepted request and wait for the outcome

Before submitting, create a local payout record and prevent two workers from submitting it simultaneously. After a successful response, store data.withdrawal_id, data.status, data.amounts, and data.fees.

pending or processing means the request is in progress. Verify and reconcile the signed withdrawal.success (with data.status: "completed") or withdrawal.failed event before updating the final state shown to the customer. Event handling must be idempotent so duplicate callbacks cannot duplicate ledger changes.

The recipient’s net amount can differ from the requested amount according to the merchant’s fee-payer settings. Use the response and signed event’s net amount and fee breakdown; do not promise the requested amount as a guaranteed received amount.

4. Handle timeouts without sending a second payout

The public withdrawal request does not document an Idempotency-Key header or a client-supplied payout ID. A network timeout can occur after the server accepted a withdrawal.

Result	What your application should do
Accepted, with a withdrawal ID	Store the ID and wait for the verified final event.
Validation or permission error	Correct the reported fields or merchant setting before considering a new submission.
Timeout or connection lost after submission	Mark the attempt as uncertain and reconcile through merchant tooling or support. Do not automatically submit another payout.
Verified completed event	Record completion once, correlated to the withdrawal ID.
Verified failed event	Reconcile the reported outcome and balance before deciding whether another payout is appropriate.
Duplicate final event	Acknowledge the stored outcome without applying it twice.

Keep your own business ID, recipient, amount, selected network, attempt time, and returned withdrawal ID in the payout record. A local lock prevents concurrent submissions, but it cannot prove whether an interrupted remote request was accepted.

Can I send batch or automatic recurring payouts?

The documented operation submits one withdrawal. There is no public batch payout endpoint or recurring-payout scheduler in this contract. An application that schedules several payouts must track and reconcile each one separately, respect rate limits, and stop automatic retries when the result is uncertain.