Deposit requests with exact amounts
Expiry windows, QR codes and idempotency on your own reference. Underpayments stay open for a top-up; overpayments are reported with the real figure received.
USDT deposit gateway
Accept USDT deposits without building blockchain infrastructure.
ZyntrixPay generates a dedicated deposit address for every client, watches TRON and BSC for the transfer, and fires a signed webhook the moment it confirms. Request a withdrawal whenever you need one — it’s reviewed and sent from our treasury.
USDT on TRC20 & BEP20
HMAC-SHA256 signed API
Ed25519 webhooks
2
Networks live — TRON (TRC20) and BSC (BEP20)
100%
Withdrawals reviewed by a person before funds move
1%
Default platform fee per confirmed deposit
120/min
API requests per key, with
Retry-After backoff
How it works
Four moving parts. You never touch the chain directly.
From creating a deposit request to a client’s balance updating — the whole path, with nothing hidden in the middle.
We generate the address
Every client gets a dedicated deposit address the moment you create them in the merchant panel — no wallet setup and no keys to manage on your side.
Create a deposit request
POST /v1/orders with an amount and your client’s reference. Back comes that address, the exact amount, a QR code and an expiry window.
We watch the chain
Our scanners follow both networks, wait for your configured confirmations, and stay a safety margin behind the chain head so a reorg never credits money twice.
You get a signed callback
An Ed25519-signed webhook fires on confirmation, with retries. Re-read the order and credit the client — the deposit is already sitting in your ZyntrixPay balance, ready to withdraw.
Custody, plainly
Deposits land with us. Withdrawals go through a person.
We hold the platform wallet client funds settle into — that is what custodial means, and we are not going to dress it up as something else.
- Every client still gets their own address. Deposit addresses stay dedicated per client, so a payment can always be matched to who sent it.
- Withdrawals are requests, not automatic transfers. Nothing leaves the treasury until someone on our side reviews and signs it.
- Balances are visible in real time. The merchant panel and the API show exactly what is credited and what is pending withdrawal.
- No single API call can move funds out. A withdrawal request still needs manual approval before it is signed and sent.
The trade-off, stated plainly. Custodial means you are trusting our controls, not just our code. We keep that surface small on purpose: one review step between a withdrawal request and money moving, and a balance you can always check against your own records.
What you get
Everything a deposit flow actually needs
Not a wrapper over a block explorer. The awkward parts — underpayments, reorgs, retries, expiry — are handled, because they are the parts that break integrations.
Webhooks that survive your outage
Ed25519 signatures, retries with backoff, and one idempotency key per credit event — so a partial payment, a re-confirmation and a reorg reversal each arrive exactly once.
HMAC-signed API
Every request carries a timestamp, a body hash and an HMAC-SHA256 signature inside a ±300 s window. Replays and tampered bodies are rejected before they reach a handler.
Reorg-aware confirmations
Thresholds are yours to set — 20 blocks on TRON and 15 on BSC by default. The scanner also stays a margin behind the chain head, so a rollback never becomes a double credit.
Hosted checkout page
A payer-facing page with the address, the QR and a live status, served from the same origin as your API. Use it as-is, or take the data and render your own.
Merchant panel with 2FA
Two-factor authentication and a verified email are required before the panel unlocks. Built-in webhook tester shows exactly what your endpoint replied — status, error and latency.
Deposit address strategy
Pick how addresses map to your clients
All three are supported. Most brokers use hybrid — it keeps the full deposit-request experience while keeping one address per client for clean reconciliation.
| Per-order | Hybrid Recommended | Per-client raw | |
|---|---|---|---|
| Address | Fresh, one-shot | Client’s permanent address | Client’s permanent address |
| Expected amount | Yes | Yes | No |
| Under / overpay tracking | Yes | Yes | No — every transfer is just a deposit |
| Expiry window | Yes | Yes | Never expires |
| Best for | One-off invoices | Recurring broker deposits | “Send anything, any time” top-ups |
Why hybrid usually wins. A permanent address per client means every deposit from the same client lands in one place, which keeps your reconciliation simple without losing per-order tracking, expiry windows or over/underpayment detection.
For your engineers
One signed POST, and you have an address.
JSON over HTTPS, amounts as decimal strings, idempotent on your own reference. No SDK to adopt and no lock-in — the whole surface is about a dozen endpoints.
-
Idempotent by design. Re-sending the same
merchant_referencereplays the original order instead of creating a second one. - Test before a single coin moves. Send a real signed webhook from the panel and read back your endpoint’s status, error and latency.
- Full integration guide on signup. Onboarding, auth, webhooks, withdrawals and an error reference — written for the engineer doing the work.
// Sign the request: timestamp . METHOD . path . sha256(body)
const ts = Math.floor(Date.now() / 1000).toString();
const body = JSON.stringify({
merchant_reference: 'DEP-1042',
chain: 'TRON',
amount: '250',
client_ref: 'user-42',
ttl_seconds: 1800
});
const hash = createHash('sha256').update(body).digest('hex');
const sig = createHmac('sha256', API_SECRET)
.update(`${ts}.POST./v1/orders.${hash}`)
.digest('hex');
const res = await fetch(`${BASE_URL}/v1/orders`, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-Api-Key': API_KEY_ID,
'X-Timestamp': ts,
'X-Signature': sig
},
body
});
// → { address: 'TQn9…', amount: '250', status: 'pending',
// checkout_path: '/checkout?order=…', expires_at: '…' }
Questions
The things people ask first
Which assets and networks are supported?
USDT only, on two networks: TRON (TRC20) and BSC (BEP20). Keeping the surface narrow is deliberate — these two carry the overwhelming majority of broker deposit volume, and every confirmation rule, fee estimate and settlement path is tuned for them specifically.
Do you ever hold my clients’ funds?
Yes. Deposits are credited to your balance in our platform wallet. You withdraw by request — someone on our team reviews and signs it before anything moves. We keep that review step manual on purpose.
How long does a deposit take to confirm?
It is bounded by the network and by the confirmation threshold you set — 20 blocks on TRON and 15 on BSC by default. Lower thresholds credit faster and carry more reorg risk; the defaults are chosen so a reversal is very unlikely. Your customer sees a “payment detected” state the moment the transfer appears, well before it is credited.
What happens if a client sends the wrong amount?
Both directions are handled. A short payment fires order.underpaid and the order stays open, so the client can top up — each partial payment fires another event with the running total. An excess fires order.overpaid with the real amount received, which is what you should credit.
How do I get my funds out?
You request a withdrawal through the API or the merchant panel. Once it is reviewed and approved, we sign and send it from the platform treasury — you do not need your own signing infrastructure or gas management.
Can we test the integration before going live?
Yes. The merchant panel sends a real, correctly signed webhook to your configured URL and shows you exactly what your server replied — status code, error body and latency. No deposit, no waiting for confirmations. Run it once per event type before you take real money.
Ready to take USDT deposits properly?
Tell us about your platform and your expected volume. We will walk you through onboarding, confirmation settings and the integration model that fits.