Payment pages, without custody.

Create a payment

Rate limit: 30 requests / 60 seconds (creation · per merchant). Shared counters and additional IP limits.

curl -X POST https://api.dedyx.com/api/v1/payments \
  -H 'X-API-Key: YOUR_API_KEY' \
  -H 'Idempotency-Key: order-1024' \
  -H 'Content-Type: application/json' \
  -d '{
    "amount": "49.00",
    "merchant_wallet": "TRzsBvFUhcvsy45ebmaKZ9EXw7zUorVkUm",
    "description": "Order #1024"
  }'

Unknown fields are rejected. Asset and network are fixed: USDT on TRON/TRC-20. Configure callback_url through merchant webhook settings, not in this request.

{
  "payment_id": "pay_0123456789abcdef0123456789abcdef",
  "expected_amount": "49.00",
  "status": "PENDING",
  "payment_url": "https://pay.dedyx.com/checkout/pay_0123456789abcdef0123456789abcdef"
}

Payment lifecycle

The amount must match exactly and the blockchain timestamp must be between created_at and expires_at. A smaller or larger transfer is recorded for reconciliation, while the order continues waiting for the exact amount. Separate transfers are not automatically summed.

Late transfers and payments to canceled or expired orders require reconciliation. Dedyx does not move or refund funds.

Reusing a wallet address

Use the same address for concurrent orders with distinct exact amounts. Only one unfinished PENDING/CHECKING/REVIEW order per address and amount is allowed; 7, 7.0 and 7.00 reserve the same amount. After PAID, CANCELED or EXPIRED, the amount can be reused. The amount remains reserved through the 10-minute CHECKING period, then is released when the worker processes final expiry. Each order requires one transfer of the full exact amount inside its payment window; partial transfers are not added together.

For example, create three orders at 15:58 for 5.00, 7.00 and 9.00 USDT on one address. A confirmed 7.00 USDT transfer inside the corresponding payment window pays only the 7.00 order; the other two keep waiting. A transfer timestamped before an order was created cannot pay it. Wait for authenticated PAID or a verified webhook before fulfillment.

One address cannot belong to different merchants. For each new order use a new idempotency key. Previously recorded transaction events cannot be applied again.

Retry safely

Idempotency-Key accepts 8–128 ASCII letters, digits and ._:-. Identical retries within the default 24-hour retention return the original 201 response with Idempotency-Replayed: true. A changed body with the same key returns 409. The replay contains the creation response; use details for current status.

Without this header, retrying after a lost response can create an unwanted order after the previous one completes. After retention expires, reconcile before retrying.

Read, list and cancel

Rate limit: 120 requests / 60 seconds (shared reads · per merchant). Shared counters and additional IP limits.

Authenticated details include transaction ID, event index, callback URL and reconciliation reason. The checkout’s public endpoint does not expose those private fields.

Rate limit: 120 requests / 60 seconds (shared reads · per merchant). Shared counters and additional IP limits.

Response: {items, next_cursor}. Start without a cursor, then pass the returned cursor. A null cursor marks the end. Limit: 1–100. Cursors belong to the authenticated merchant.

Rate limit: 120 requests / 60 seconds (shared reads · per merchant). Shared counters and additional IP limits.

Legacy offset pagination: limit 1–100, offset 0–10000.

Rate limit: 120 requests / 60 seconds (public status · per payment token). Shared counters and additional IP limits.

No API key required. Use the token from payment_url. All viewers of the same payment share its status counter; this counter is separate from merchant reads.

Rate limit: 60 requests / 60 seconds (cancellation · per merchant). Shared counters and additional IP limits.

Only an active PENDING order can be canceled. Cancellation does not return blockchain funds.

Verification after the sending deadline

After expires_at, do not send funds. CHECKING lasts until verification_until (expires_at plus 10 minutes). The address and amount stay reserved. A confirmed exact transfer with a blockchain timestamp inside the original window can still pay the order during CHECKING. After verification_until, even if the worker restarted or was delayed, timely transfers need manual reconciliation. Cancellation prevents automatic confirmation. Detection may take a few minutes after blockchain confirmation, depending on indexing, the verification schedule and service capacity. API responses include server_time for checkout timing; it is not proof of a successful blockchain scan.

Wallets and exchange withdrawals

The payment QR contains only the recipient address. Select USDT on TRON and enter the exact payment amount in your wallet. Wallet-specific amount autofill is currently disabled on payment pages.

TronLink, TokenPocket and OKX Wallet are in the compatibility review. Their transfer/login or connection protocols differ, so the address QR and manual amount are the fallback; we do not claim universal amount autofill. For Binance and OKX exchange withdrawals, choose USDT and TRON (TRC-20), then check the exact receiving amount after fees. On Binance, choose Receive amount when available; entering a Withdrawal amount can deduct the fee from what the merchant receives. A withdrawal request submitted before deadline may reach a block after it and require reconciliation.

Ordinary address QR and copying remain available. Wallet-specific formats require separate compatibility checks before release.