Operate safely
Telegram bot and private support
Wallet sessions, private support tickets and owner-only administration in the Mercenta Telegram bot.
The official @mercentabot opens the Mercenta Mini App. It runs on the operator's VPS using long polling and SQLite; no paid Redis or webhook service is required.
Wallet connection and locking
An encrypted wallet and a login session serve different purposes:
- The encrypted wallet stays on the device. Reloading or five minutes of inactivity locks its signer; unlocking requires the password.
- A valid authenticated session allows viewing account data while the signer is locked. Locking or switching Testnet/Mainnet must not delete that session.
- Signing in and sending funds require separate explicit confirmations. An expired session requires signing in again; connection is not guaranteed to remain valid forever.
- Only public wallet-source and network preferences are remembered. Private keys and passwords are not stored unencrypted.
Keep an encrypted backup and its password separately. Mercenta cannot recover a lost client key.
Private support
Use /support in your private chat with the bot to open an appeal. Use /tickets to find your own conversations and /cancel to leave message-entry mode.
An appeal has an owner, a message history and an open/closed status. Replies are sent only to the owner's private chat. Customers cannot list, read, answer or close another customer's ticket, even if they know its number. Support messages are not handled in group chats.
Text support does not need your private key, wallet password, recovery phrase or activation code. Never send them. Include an order reference and a short problem description instead.
Owner administration
The operator sets TELEGRAM_ADMIN_ID on the VPS. The bot checks the authenticated sender ID, private chat and action permissions on every privileged operation. A callback ID or a hidden button is not an authorization mechanism.
/admin provides ticket management, customer selection and direct messages, closure/reopening, notifications and storefront controls. Closing a ticket preserves its history. Direct customer messages are scoped to the selected conversation, not broadcast to everyone.
Storefront pause/resume controls affect bot navigation only. They do not transfer funds, alter network contracts or override the commerce server's payment safeguards.
Purchase history integration
The Telegram bot and the authoritative fulfillment database can be hosted on different servers. Order metadata must be supplied through a separately authenticated, read-only bridge. The optional TELEGRAM_ORDERS_ENDPOINT and orders-read-key systemd credential enable that bridge after the fulfillment service is configured.
History contains only order references, product names, exact amounts, network, status and timestamps. Activation codes, upstream payloads and wallet private keys must never be returned through the admin history endpoint. A client-posted receipt or wallet address is not independent payment evidence.
If the bridge is unavailable or not configured, the bot reports that history is unavailable. It does not present an empty or fabricated purchase history as complete. Linking a Telegram identity to a wallet requires verified ownership; merely sending an address in chat must not grant access.
Operations
The bot database stores language preferences, update offsets and support records. Keep it private and back it up using SQLite's backup mechanism. Do not publish it with the customer storefront starter.
The official administrator ID and credentials are operator settings, not defaults for copied customer shops. Telegram must allow a private conversation with the owner before notifications can be delivered. Delivery errors do not mean a customer message or order succeeded; check the service status and retry safely.