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 WhatsApp Business becomes a sales channel
Customer writes in messenger, confirms order details, receives invoice and expects a quick way to pay.
For salons, delivery, local stores, service companies, consultations and B2B sales, WhatsApp Business often becomes a lightweight storefront or CRM chat. Customer asks about price, availability, address, timing, package or delivery terms and expects the next step in the same conversation.
WhatsApp should not be described as directly processing a bank payment. Correct flow is different: manager, bot or backend creates payment link, customer opens protected checkout page, pays, and business receives verified payment status by webhook or status lookup.
- WhatsApp remains the communication and payment link delivery channel;
- payment happens on protected checkout page;
- backend stores order_id, customer id, amount and link expiration;
- final paid, failed or expired status arrives by webhook or status check.
How WhatsApp payment link flow works
A link can be sent manually by manager or created dynamically by backend and API.
For MVP, use fixed payment links: consultation prepayment, delivery, deposit, service package or fixed-price product. Manager sends the correct link in WhatsApp Business together with order summary.
For variable amounts and unique orders, backend should create dynamic payment request through API: order_id, amount, AMD currency, customer phone or internal customer_id, expiration, description and CRM metadata. After payment, VPOS webhook updates payment journal, CRM, spreadsheet, Bitrix24 or amoCRM.
- fixed links work for a simple pilot;
- dynamic API links connect payment with unique order and amount;
- expiration protects against old links;
- webhook closes order after server-side verification;
- CRM receives normalized payment event instead of manual note.
Technical controls and reconciliation
WhatsApp sales need the same controls as website and CRM: idempotency, statuses, audit and safe secrets.
Core rule is idempotency. Customer can open link several times, manager can resend it, and webhook can arrive more than once. Backend should connect events to one order_id and avoid duplicate paid orders, access grants or delivery tasks.
Fiscalization, acquiring bank, contracts, refunds, partial refunds and delivery rules depend on concrete business and provider. Before public launch, define failed, expired, pending, duplicate payment, cancellation and refund handling.
- idempotency key for payment request and webhook processing;
- order_id and customer identifiers for WhatsApp and CRM search;
- paid, failed, expired, pending and manual review statuses;
- API/webhook secrets in environment variables;
- reconciliation of provider report, CRM orders, refunds and accounting documents.
FAQ
Can payment be accepted directly in WhatsApp Business?
WhatsApp Business can be communication channel and place where the payment link is sent, 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 links and payment journal. Unique orders, CRM statuses and automation work better with API and webhooks.
Can screenshot confirm payment?
Screenshot can help communication, but paid status should appear after server-side verification: webhook, status lookup, amount, currency and order_id.
