TronDealer now detects and settles native-coin deposits — Bitcoin (BTC), BNB, Ether (ETH), Polygon (POL), TRON (TRX) and Solana (SOL) — on the same multi-client pipeline as USDT and USDC. Automatic per-chain detection, USD-equivalent webhooks with amount_native and price_usd, HMAC-SHA256 signatures, and auto-sweep to your wallet or custodial payout via QvaPay and Zelle.
For most of our history TronDealer was a stablecoin-first gateway: USDT and USDC, dollar-denominated, zero volatility. That is still the core. But merchants kept asking the same question —"my customer only has BNB / ETH / SOL, can I charge them anyway?"— and the answer is now yes.
Starting today, TronDealer detects and settles native-coin deposits on the same multi-client pipeline you already use for stablecoins. Six assets ship in this release: Bitcoin (BTC), BNB, Ether (ETH), Polygon (POL), TRON (TRX) and Solana (SOL).
amount_native and price_usd so you never guess conversions.detected → confirmed → notified → swept.Stablecoins are perfect for customers already inside crypto. But a large slice of the market holds value in the assets they bought first —Bitcoin, Ether, BNB, SOL— and never converted to USDT. Every time your checkout only speaks stablecoin, those customers bounce.
Accepting native coins closes that gap without adding operational risk, because TronDealer still reports value in USD. The customer pays in BNB; you see $24.80 with the exact amount_native and the price_usd used. Your accounting stays dollar-denominated even when the rail is volatile.
This is the important part, so read it before you integrate.
bsc, ETH on eth, POL on pol, TRX on tron, SOL on sol, BTC on btc. ETH sent to an Arbitrum/Base wallet and AVAX are not deposit assets — they are only handled as gas residue.There are also minimum thresholds. Anything below these is ignored entirely (not detected, not notified, not swept), because it wouldn't cover its own sweep cost:
| Coin | Chain | Min. deposit | Default confirmations |
|---|---|---|---|
| BTC | Bitcoin | ~0.0001 BTC | 2 |
| BNB | BSC | 0.001 BNB | 10 |
| ETH | Ethereum | 0.0002 ETH | 10 |
| POL | Polygon | 7 POL | 20 |
| TRX | TRON | 2 TRX | 19 |
| SOL | Solana | 0.005 SOL | 1 (finalized) |
A native deposit rides the exact same four-state lifecycle as a stablecoin payment:
If you already integrate stablecoins, you don't change anything. You assign a deposit wallet on the chain you want, and if the customer sends the native coin instead of the token, it just works.
Same endpoint you already use. Assign a wallet on bsc (or eth, pol, tron, sol, btc) and share the address with your customer.
x-api-keyNative-coin webhooks use the same envelope as stablecoins, with three fields that carry the conversion. Here is a transaction.incoming for a BNB deposit:
{
"event": "transaction.incoming",
"timestamp": "2026-07-17T14:03:11.204Z",
"data": {
"tx_hash": "0x9f2c…",
"block_number": 44120981,
"from_address": "0x1a2b…",
"to_address": "0x8c7d…",
"asset": "BNB",
"amount": 24.80,
"amount_native": 0.04,
"price_usd": 620.00,
"confirmations": 3,
"wallet_label": "order-1024",
"network": "bsc"
}
}amount — USD equivalent (what you charge and reconcile against).amount_native — the on-chain amount actually received.price_usd — the transparent spot used for the conversion.Because the envelope is identical, your existing stablecoin handler already works. The only new thing to notice is the asset field (BNB, ETH, POL, TRX, SOL, BTC) and the two conversion fields.
function handleWebhook(payload) {
const { asset, amount, amount_native, price_usd, network, wallet_label } = payload.data
// amount is always USD — reconcile the order the same way for every asset
markOrderAsPaid(wallet_label, amount)
// Optional: show the customer what they actually sent
if (amount_native != null) {
console.log(`${wallet_label}: ${amount_native} ${asset} on ${network} ($${amount} @ $${price_usd})`)
}
}The X-Signature-256 header is computed exactly as before —HMAC-SHA256(webhook_secret, raw_body)— and the retry policy is unchanged.
Native deposits support the same payout methods as the rest of TronDealer:
Rather than invent testimonials, here are the concrete patterns we built this for. Swap in your own numbers as you roll it out:
TronDealer is built by QvaPay, and native-coin settlement plugs straight into that ecosystem:
If you have a partnership or high-volume use case you want featured here, write to us —we're actively collecting real deployment stories to add to this page.
Native coins are a foundation, not the finish line. What's next, in order:
If you already have a TronDealer account, there's nothing to configure. Assign a wallet on the chain you want and the native coin is detected automatically. Your existing API key and webhooks cover every asset.
If you don't have an account yet, register free at /onboard, pick your payout method, and start charging in minutes. Full API reference lives at trondealer.com/docs.
Native coins are live but we keep polishing the edges. If your use case needs something we haven't covered —an asset, a chain, a settlement path— write us at [email protected] or open an issue on the WooCommerce repo.
curl -X POST https://www.trondealer.com/api/v2/wallets/assign \
-H "x-api-key: td_your_api_key" \
-H "Content-Type: application/json" \
-d '{ "network": "bsc", "label": "order-1024" }'The customer sends BNB (or ETH, POL, TRX, SOL, BTC) to that address as a normal, direct on-chain transfer. No memo, no wrapping, no bridge.
The transaction.incoming and transaction.swept events arrive with the value already resolved to USD, plus the native amount and the reference price.