Key takeaways
Define the reseller boundary
List the operations exposed by the current provider documentation: plans, quotes, invoices, provisioning, status, renewal, or revocation. Do not infer an endpoint from marketing copy. The VPN Partner API contract should define authentication, errors, rate limits, and lifecycle.
Assign responsibility for checkout, taxes, refunds, support, abuse, and data requests. A reseller brand does not remove the infrastructure provider or payment processor from the data flow.
Keep Telegram outside the trust core
Telegram documents bot methods at Receive the user command, then call your backend over an authenticated internal path. Never embed the provider API key in bot messages, callback data, browser code, or a public repository.
Use an internal user and order identifier. Check authorization before displaying subscription status or an access page. Limit sensitive content in notifications and logs.
Make orders idempotent
Create an idempotency key for each purchase attempt and preserve it across retries. A timeout does not prove failure. Query status or reconcile before creating another invoice or VLESS profile.
Store provider event IDs and process each webhook once. Verify signatures and timestamps according to provider documentation. Reject unsigned status changes. Use bounded retries and a dead-letter or review queue for uncertain events.
Deliver and rotate access safely
Show the VLESS profile on an authenticated private page or bot session. Treat links and QR codes as credentials. Do not include them in analytics, exception traces, or support exports.
Implement rotation after disclosure and revocation after refund or abuse according to the contract. To resell VLESS access, support staff need an order lookup that does not reveal the full key.
Test failure paths before launch
Test delayed payment, duplicate webhook, provisioning timeout, provider 429 response, revoked API key, failed renewal, refund, expired access, and provider outage. Confirm that a retry cannot double-charge or create duplicate credentials.
Use a sandbox where available and a limited production rollout. Monitor counts and state transitions without logging secrets. Publish accurate support ownership and commercial terms to the buyer.
Reconcile money and access as separate state machines
Model the reseller order, provider invoice, payment observation, profile provisioning, delivery, renewal, refund, and revocation as separate records linked by internal identifiers. A paid state does not prove that access was issued, and a delivery message does not prove that the buyer could retrieve it. Define allowed transitions and reject a late or duplicate event that would move a completed order backward.
Preserve one idempotency key for the same purchase attempt. After a timeout, query the existing order or place it in review instead of creating a new invoice. Store provider event identifiers and the verification result, not the full credential. Reconciliation should find paid orders without access, issued access without confirmed delivery, refunds awaiting revocation, and renewals applied to the wrong profile.
Test each uncertainty with provider documentation that applies to the authenticated API version. The Telegram Bot API at describes message transport; it does not define the provider's invoice or webhook contract. Record expected status, received status, retry decision, user message, and manual recovery owner for every failure case.
Operate the secret and support lifecycle
Inventory the Telegram token, provider API key, webhook secret, payment credential, database encryption key, and administrative access. For each secret, document where it is stored, which service can read it, how it is rotated, and which logs or error reports must redact it. Use separate test and live credentials where the provider supports that boundary.
Design support views around orders and lifecycle events. Staff should see timestamps, sanitized provider responses, delivery status, expiry, and permitted recovery actions without seeing a reusable VLESS link by default. A controlled rotation action is safer than copying a credential into a ticket. Publish which organization handles payment questions, connection problems, refunds, data requests, and abuse reports.
Before launch, revoke a test API key, rotate a webhook secret, replay a duplicate event, simulate a provider outage, and confirm that buyers receive an accurate status instead of a second charge. API resale is appropriate only when the team can monitor and reconcile these states after the initial bot message has been sent.
Continue reading