Key topics
Related public pages
If you need the product, API or operations page rather than only the article, start with these VPOS.am sections.
Why Telegram becomes a sales point
Customer already talks to the bot, chooses a service and expects a quick payment step without a separate website.
For online schools, appointments, delivery, local e-commerce, consultations and private clubs, Telegram often becomes the first sales interface. Customer writes to the bot, chooses a course, package, delivery slot, consultation or subscription and wants to finish the flow in the same chat.
The interface should not be confused with payment infrastructure. Telegram bot should not be described as directly processing the bank payment. A correct architecture is different: bot or backend creates payment link, user opens protected checkout page, pays, and backend receives final status by webhook or status lookup.
- Telegram remains the interface for selection and notifications;
- payment happens on a protected checkout page;
- backend stores order_id, telegram_user_id and amount;
- final paid status arrives by webhook or status check.
How the flow works
Basic flow: service selection in bot, payment link, checkout, webhook and automatic continuation.
The scenario starts in Telegram bot. User chooses a service: lesson, consultation, delivery, donation, tip, club access or catalog item. Bot collects minimal context: selected product, amount, currency, telegram_user_id, language, contact data, delivery slot or another business parameter.
User opens protected checkout page and pays by available provider method. VPOS sends webhook to backend. Backend validates signature, status, amount, currency, order_id and idempotency key, stores result in payment journal and only then tells bot that order, access, request or subscription is confirmed.
- user chooses service, tariff or order in bot;
- bot/backend creates payment link or payment request;
- user pays on checkout page;
- VPOS sends payment result webhook;
- bot confirms order, access, request or subscription.
MVP, technical controls and CRM sync
Start from fixed links and a payment journal, then move to API, idempotent webhooks and CRM integration.
Fastest pilot is fixed payment links. Next level is dynamic links through API: bot sends selected service and user to backend, backend creates unique payment request, stores order_id and sends link back to Telegram. After payment, webhook updates payment journal, bot and CRM.
Reliable flow needs idempotency, order_id, telegram_user_id, paid/failed/expired statuses, repeated webhook handling, token security, logs and audit trail. Fiscalization, acquiring bank, contracts and refund rules depend on concrete business and provider.
- fixed links for MVP and dynamic API links for unique orders;
- webhooks for automatic paid, failed and expired statuses;
- payment journal for support and reconciliation;
- CRM, spreadsheet, Bitrix24 or amoCRM as next step;
- fiscalization and provider requirements reviewed separately.
FAQ
Can payment be accepted directly inside Telegram bot?
Bot can be order interface and send payment link, but bank payment should happen through protected checkout page or supported provider flow. Telegram itself should not be treated as the payment provider.
How does bot know that payment is completed?
VPOS sends webhook to backend. Backend validates status, amount, currency, order_id and idempotency, then tells bot to confirm order or access.
What if webhook arrives twice?
Handler should be idempotent: repeated webhook for the same payment or order must not grant access twice, create second order or duplicate CRM payment.
