USDT settlement for DHRU
Accept stablecoin. Credit instantly.
TRC20, BEP20, and Binance Pay routed to DHRU on or off chain confirmation. No middlemen, no manual reconcile.
99.98%
Webhook uptime
~38s
Median credit time
Built to settle on
- USDT TRC20
- USDT BEP20
- USDC BEP20
- Binance Pay
Why TriaPay
The features operators actually use.
Built by people who run DHRU panels. None of the bloat.
-
Hardened by default
TLS 1.3, encrypted at rest, full audit trail.
-
Idempotency keys
Retries are safe. Same key, same response, no double credit.
-
Sub-minute credit
We watch the chain in real time and post the webhook the moment confirmation lands.
-
Multi-chain, multi-asset
USDT TRC20, USDT/USDC BEP20, Binance Pay. Switch per order.
-
Key rotation
Rotate API keys and webhook secrets without downtime. Old keys gracefully drain.
-
Signed webhooks
HMAC-SHA256 over timestamp + idempotency + body. Replay-proof and tamper-evident.
How it works
Four steps from deposit to credit.
- 01
Customer picks USDT
In your DHRU deposit page they select USDT TRC20, BEP20, or Binance Pay.
- 02
They send the exact amount
We allocate a short match code embedded in the amount decimals or memo.
- 03
Chain confirms
Listeners observe the transaction and verify the match code in real time.
- 04
DHRU credited
We sign a webhook to DHRU. addPayment runs. Tenant balance updated.
Pricing
One feature set. Pick the billing period.
Same access on every plan. Longer commitments save more.
- All payment methods enabled
- Unlimited webhook retries with exponential backoff
- Sandbox mode + audit log included
FAQ
Frequently asked
What operators ask before they wire the plugin in.
General
No. Binance Pay C2C uses a personal Binance account API key with Read and Pay permissions. No KYB required.
Each order gets a random match code with a configurable width: 1 to 3 digits for crypto chains (encoded in the trailing decimals of the amount, e.g. $10.0123) and 3 to 5 digits for Binance Pay (placed in the note field). Codes are scoped per tenant; the matcher disambiguates by master address so different tenants can hold the same active code.
USDT on Tron (TRC20). USDT and USDC on BNB Smart Chain (BEP20). USDT and USDC on Binance Pay C2C. Ethereum and Polygon are on the roadmap once gas economics make sense for sub-$50 invoices.
TRC20 and BEP20 listeners scan every 3 seconds, Binance Pay every 5 seconds. End-to-end credit is typically 3–7 seconds for crypto and 5–10 seconds for Binance Pay, plus the chain confirmation tail. BSC push subscriptions and Binance merchant webhooks are on the roadmap for sub-second detection.
The transaction lands in the orphan reconcile queue rather than auto-crediting an expired order. An admin can rebind it to the right invoice and trigger a manual recredit. Overpayments on still-valid orders are credited and flagged as overpaid.
Pricing and billing
Only the billing period differs. Longer commitments unlock a discount because they reduce churn and payment processing overhead. Switch periods anytime from the dashboard.
Full refund within the first 7 days, no questions asked. After that, refunds are pro-rated for unused billing periods on annual or half-year plans.
Service continues until the end of the current billing period. Annual and half-year plans get pro-rated refunds for unused months. No re-activation fee if you come back later.
Technical and security
Sensitive fields are encrypted at rest, traffic is TLS-only, and passwords use modern memory-hard hashing. Two-factor authentication is available on every account. Every privileged action is audit-logged with the real client IP. Specifics are documented for integrators in our developer docs.
Each delivery is cryptographically signed and timestamped; the bundled DHRU plugin handles verification automatically. For custom integrations, the signature format and verification steps are in the webhook spec under our developer docs.
Same key plus same payload returns the original order, no duplicate. Same key plus a different payload now returns HTTP 409 with `code: "conflict"` so accidental key collisions are visible instead of silently reusing the prior order.
Yes. Login is a password step plus a one-time code delivered by email (default), WhatsApp (when a phone is configured), or an authenticator app for accounts that have enrolled it. Replay protection prevents codes from being used twice. A 7-day "remember this device" option skips the code on a recognized device; you can revoke devices anytime from the dashboard.
Yes. Open Integration in the dashboard. Live webhook secrets and live API keys can be regenerated at any time; rotations require an email OTP and are audit-logged. Sandbox keys and sandbox secrets can be regenerated freely.
Each tenant has a parallel sandbox key (`pk_test_*`) and sandbox webhook secret. Orders created with the test key are isolated; chain listeners physically cannot pick them up. Force-match, force-credit, and force-expire endpoints simulate the full webhook round-trip. The DHRU plugin honors `X-Payment-Mode: sandbox` and short-circuits before crediting any real invoice.
DHRU Fusion. Plugin uses standard gateway hooks, no schema changes required. Compatible with PHP 7.4+.
Orphan transactions surface in the admin reconcile UI. An admin can manually bind any incoming transaction to the correct invoice and trigger a recredit. The recredit action requires a fresh OTP confirmation.
Listeners record every incoming transaction. If no order matches, the transaction lands in the orphan reconcile UI where admins can bind it to the correct invoice and trigger a recredit. No payment is ever silently lost.
Support
WhatsApp replies within one business day on every plan. Critical incidents (listener down, credit failure) escalate to same-day response. Self-serve dashboard covers most operations without a ticket.
Operator identity
Online-only operator. Reachable directly.
No fronting company, no support queue. You message the operator and you get the operator.
Operator
RBW-Tech
Hours
Asia-Pacific, daily 09:00 to 24:00 (UTC+7)
Response
Median 4 hours during stated hours