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 Facebook Messenger remains a sales channel
Customer often writes to Page inbox, confirms order details and expects a clear way to pay without opening a complex website.
For local stores, delivery, salons, online schools, service companies and B2B contractors, Facebook Page and Messenger remain a practical sales point. Customer sees a post, ad or recommendation, opens messages, confirms price, availability, size, delivery address, appointment time or service scope and expects the next step in the same channel.
Facebook Messenger 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 server-side status lookup.
- Facebook Page and Messenger remain communication and payment link delivery channels;
- payment happens on protected checkout page, not inside the chat;
- backend connects link with order_id, amount, currency and customer;
- order, access or delivery is confirmed after verified status.
How Facebook Page payment link flow works
A link can be sent manually after conversation or created dynamically by API when amounts, goods and timing differ.
A simple MVP can start with fixed links: consultation prepayment, appointment deposit, delivery, popular product, lesson package or standard service. Manager sends the correct link in Messenger and records order in spreadsheet or CRM.
For unique orders, backend should create payment request through API: order_id, amount, AMD currency, expiration, customer id, channel, order description and CRM metadata. After payment, VPOS webhook updates payment journal, CRM, spreadsheet, Bitrix24 or amoCRM.
- fixed links work for pilot and standard services;
- dynamic API links connect payment with unique order and amount;
- expiration protects against old or no longer valid links;
- webhook closes order after server-side verification;
- CRM receives normalized payment event instead of manual comment.
Technical controls and reconciliation
Social channels create quick conversations, but payment backend needs strict controls: idempotency, statuses, audit and safe secrets.
Core rule is idempotency. Customer can open the link several times, manager can resend it, webhook can arrive again, and CRM integration can temporarily fail. Backend should treat repeated event as already known 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 paid, failed, expired, pending, duplicate payment, cancellation, refund and manual correction handling.
- idempotency key for payment request, webhook processing and CRM sync;
- order_id plus channel/customer identifiers for order search;
- paid, failed, expired, pending and manual review statuses;
- API/webhook secrets only in environment variables and server storage;
- payment journal for provider report, CRM orders, refunds and accounting reconciliation.
FAQ
Can payment be accepted directly in Facebook Messenger?
Messenger 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 payment links and payment journal. Unique orders, CRM statuses and automation work better with API, webhooks and idempotency.
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.
