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.
Bot should create payment request, not accept money itself
Telegram or WhatsApp bot is a convenient order interface, but payment parameters should be fixed by backend.
Bots often mix conversation, order, payment and support in one flow. Without backend payment request, user can change amount, manager can send the wrong link and CRM cannot know which order should close after payment.
The safer model is: bot collects minimum data and asks backend to create payment request. Backend verifies cart or service, amount, currency, expiration, customer reference and scenario access. Only then does the bot send payment link to the user.
- do not calculate amount only inside bot;
- create payment request with order id and customer id;
- set expiration and idempotency key;
- do not keep payment secrets in bot runtime.
Paid should appear only after server-side verification
Screenshot, user message or success page are not payment proof for CRM.
A user can write "paid" in chat, send a screenshot or close the page after redirect. None of these actions should change order to paid. Final business status should appear only after webhook or server-side status lookup.
Bot can show pending, accepted for review or paid, but the source of paid should be payment backend. This matters for delivery, appointment booking, reservations, deposits and B2B invoices.
- success message in bot is not paid;
- webhook should be signed and idempotent;
- late callback should not roll paid back to pending;
- manual override needs actor, reason and audit trail.
CRM and ERP should receive a normalized event
After verified payment, bot, CRM, warehouse and operator should see the same payment fact.
If bot writes paid in one place, manager writes another note and CRM receives event later, duplicates, manual checks and disputed orders appear. One normalized event should be delivered to bot, CRM, ERP, notifications and reconciliation.
If CRM or ERP is temporarily unavailable, payment status should remain stored and event delivery should retry. Operator needs failed delivery list, not manual search through chat history.
- send one payment_verified event;
- retry CRM/ERP delivery with backoff;
- do not create second order on repeated webhook;
- log chat id only when support and privacy policy require it.
FAQ
Can Telegram or WhatsApp screenshot confirm payment?
Not for automatic paid status. Screenshot can be sent to operator for manual review, but CRM/ERP should change financial status only after server-side verification.
Should the system store user chat id?
Only if it is needed for notifications or support. Treat it as personal data: minimal fields, clear retention and privacy policy coverage.
What if user pays after link expiration?
Backend should check real provider status. If payment was completed, create exception or manual review instead of silently creating a new paid order without connection to the original request.
