Operator: Dedyx, Private, Poland; address: Georgia. Support: https://t.me/dedyx_support. Privacy contact: https://t.me/dedyx_support. Registration details, where applicable: Georgia. Dedyx is the service name. Applications, access delivery and support are manual; no automated support bot or automated credential delivery is available.
Dedyx creates USDT TRON/TRC-20 checkout pages through an API, observes confirmed transfers through a blockchain provider and sends signed payment webhooks. Customers pay the merchant address directly. Dedyx does not receive wallet private keys or seed phrases, hold or move funds, exchange assets, make recurring debits or refund from a merchant wallet. Merchants handle goods, order fulfilment, refunds and customer disputes.
You need a TRON address you control, a secure backend, a public HTTPS receiver on port 443 and persistent orders/event IDs. Check the asset, network, address and amount. Never send private keys, seed phrases or API/rotation/signing credentials to Dedyx support. Do not supply unlawful content; use the service for lawful projects and transfers allowed by applicable rules. Pilot access is agreed individually, not promised across every CIS country.
The baseline pilot provides 30 days from confirmed credential receipt and operator activation, 100 successful new payment creations in total and 10 per UTC day. GET /api/v1/merchant/limits reports your actual dates, limits and remaining allowance; changes require a separate agreement. These are invoice-creation limits, not paid-order counts. Cancellation and expiry do not refund quota. Reads, webhook delivery and identical Idempotency-Key/body replays within retention do not consume creation quota; technical rate limits still apply. Persist the key, request and order mapping before the first request. Default replay retention is 24 hours; reconcile an uncertain outcome before creating again after retention.
Pilot price/payment arrangement, if any: Free. Future commercial plans are not established here. There is no automatic renewal, monthly quota reset or recurring debit. Shared provider budgets and admission can restrict creation before your quota is exhausted. Availability, confirmation latency and support response times have no guaranteed SLA.
Send one full transfer of exactly the displayed USDT amount; network fees are separate. Partial, excessive or insufficient transfers are not combined into an exact payment. Use expires_at; the current default sending window is 30 minutes. CHECKING then lasts until verification_until, a saved additional 10-minute verification window for a timely transfer. Do not send new funds during CHECKING/EXPIRED/CANCELED/REVIEW.
Network loss, a timer, screenshot, open page or receiver HTTP acknowledgement does not prove payment or fulfilment. A transfer discovered after final EXPIRED/CANCELED does not automatically become PAID: contact the merchant, then Dedyx for technical reconciliation using transaction ID/event index. Cancellation cannot reverse a blockchain transfer. With address/amount reuse, an old repeated transfer within a new order window can match the new order; use separate addresses for stronger attribution. The default QR contains the address only; check the amount manually. Unverified wallet compatibility is not promised.
Configure the receiver before creating payments. Verify raw-body HMAC signatures, timestamp/key ID, event IDs and saved-order correspondence. Delivery can repeat, be delayed or need a manual retry after attempts are exhausted; HTTP 2xx does not prove a business action. Commit event deduplication and fulfilment atomically; use your own idempotent outbox for external actions. Do not fulfil from a redirect, timer or unverified status. See API_GUIDE.md and public Docs for the contract and examples.
Expiry, quota, admission and operator pause can stop new creations. While the account remains active, reads and existing payment servicing continue; general inactive status separately blocks authenticated API access, without reversing transfers or removing existing servicing. An incident or compromise can require component isolation. The owner records decisions and reconciles existing obligations.
To end participation, complain or request data action, contact support with minimal project/merchant ID, UTC time and a description. For paid-order disputes or refunds, contact the merchant first. Support verifies account ownership through a known contact; a supplied key alone is insufficient. See support.en.md for safe reporting. Ending access does not immediately delete ledger/audit/backups or remove public TRON data.
Before activation, receive a retainable copy of the current EN/RU terms and privacy notice; version, agreement and delivery are recorded in the private pilot log. Material changes are communicated beforehand with an effective date; financial facts are not reset. Mandatory rights under applicable law remain unaffected. Contractual/consumer requirements and permitted business form must be confirmed for the real operator and selected participants before admission.