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 a Viber bot can become a sales point
Customer chooses service or order inside bot scenario, but payment status should be confirmed by server, not by chat message.
For delivery, local e-commerce, service appointments, online schools, consultations, clubs and support flows, Viber bot can be a practical entry point. User chooses category, tariff, time, address, service package or request inside a dialog and expects a clear way to pay without calling manager.
Viber should not be described as directly processing a bank payment. Correct flow is different: bot or backend creates payment link, user opens protected checkout page, pays, and backend receives verified payment status by webhook or server-side status lookup.
- Viber bot collects order context and sends payment link;
- payment happens on protected checkout page;
- backend connects order_id, viber_user_id or internal customer_id, amount and expiration;
- order, access, appointment or subscription is confirmed after server-side status.
MVP flow: fixed and dynamic links
Start can use fixed links, while unique orders need API and webhooks.
Fixed links work for simple pilot: consultation prepayment, service appointment, delivery, standard lesson package, deposit or popular product. Bot shows options, user selects item, receives link and pays on checkout page.
If amount depends on cart, address, discount, schedule or manager review, dynamic API link is needed. Bot sends user selection to backend, backend creates payment request with order_id, amount, AMD currency, expiration, viber_user_id or internal customer_id and returns link to bot.
After payment, VPOS sends webhook. Backend verifies signature or trusted status lookup, checks amount, currency, order_id and idempotency key, stores event in payment journal and gives bot the correct next step.
- fixed payment links close simple MVP in several days;
- API links connect payment with unique orders and personalized amounts;
- expiration helps avoid payment for outdated scenario;
- webhook updates bot, CRM and payment journal after server-side verification;
- chat screenshot should not be the source of paid status.
Technical controls for Viber bot payment flow
Even if interface is simple, backend must handle idempotency, repeated webhooks, statuses and safe token storage.
Core rule is idempotency. User can press payment button several times, link can be opened again, webhook can arrive more than once, and CRM can temporarily fail. Backend should connect events to one order_id and avoid duplicate access, duplicate order or duplicate bonus.
Fiscalization, acquiring bank, contracts, refunds, partial refunds, subscriptions and delivery rules depend on concrete business and provider. Before public launch, define paid, failed, expired, pending, duplicate payment, cancellation, refund and manual correction handling.
- idempotency key for payment request, webhook processing and access granting;
- order_id plus viber_user_id or internal customer_id for bot scenario binding;
- paid, failed, expired, pending and manual review statuses;
- bot/API/webhook tokens only in environment variables and server-side storage;
- logging and audit for CRM, accounting, support and provider reconciliation.
FAQ
Can payment be accepted directly in a Viber bot?
Viber bot can be scenario and payment link delivery channel, but bank payment should happen on protected checkout page or supported provider flow.
Can business start without complex development?
Yes. MVP can start from fixed payment links and payment journal. Unique orders, CRM statuses and automation work better with API, webhooks and idempotency.
How does bot know that user paid?
Backend receives webhook or checks status server-side, verifies order_id, amount, currency and idempotency key, then tells bot the next step.
