Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Бот должен создавать payment request, а не принимать деньги сам
Telegram или WhatsApp бот удобен как интерфейс заказа, но платежные параметры должны фиксироваться на backend.
В ботах часто смешивают диалог, заказ, оплату и поддержку. Без backend payment request пользователь может изменить сумму, менеджер может отправить неправильную ссылку, а CRM не поймет, какой заказ должен закрыться после оплаты.
Безопаснее, когда бот собирает минимум данных и передает backend команду создать payment request. Backend проверяет корзину или услугу, сумму, валюту, срок действия, customer reference и доступность сценария. После этого бот отправляет пользователю payment link.
- не формировать сумму только на стороне бота;
- создавать payment request с order id и customer id;
- ставить expiration и idempotency key;
- не хранить платежные секреты в bot runtime.
Paid должен появляться только после server-side verification
Скриншот, сообщение пользователя или success page не являются платежным доказательством для CRM.
Пользователь может написать в чат "оплатил", прислать скриншот или закрыть страницу после редиректа. Ни одно из этих действий не должно менять заказ на paid. Финальный бизнес-статус должен появляться только после webhook или server-side status lookup.
Бот может показать pending, accepted for review или paid, но источник paid должен быть платежный backend. Это особенно важно для доставки, записи на услугу, бронирования, депозитов и B2B-счетов.
- success message в боте не равен paid;
- webhook должен быть signed и idempotent;
- late callback не должен откатывать paid в pending;
- manual override должен иметь actor, reason и audit trail.
CRM и ERP должны получать нормализованное событие
После verified payment бот, CRM, склад и оператор должны видеть один и тот же факт оплаты.
Если бот пишет paid в одном месте, менеджер в другом, а CRM получает событие позже, появляются дубли, ручные сверки и спорные заказы. Нужен один normalized event, который доставляется в бот, CRM, ERP, уведомления и reconciliation.
Если CRM или ERP временно недоступны, платежный статус должен остаться сохраненным, а доставка события должна повторяться. Оператору нужен список failed deliveries, а не ручной поиск по чату.
- отправлять одно payment_verified event;
- повторять доставку в CRM/ERP с backoff;
- не создавать второй заказ при повторном webhook;
- логировать chat id только если это нужно для поддержки и privacy policy.
FAQ
Можно ли подтверждать оплату по скриншоту в Telegram или WhatsApp?
Нет для автоматического paid-статуса. Скриншот можно отправить оператору на ручную проверку, но CRM/ERP должна менять финансовый статус только после server-side verification.
Нужно ли хранить chat id пользователя?
Только если он нужен для уведомлений или поддержки. Его нужно хранить как персональные данные: с минимальным набором полей, понятным сроком хранения и ссылкой на privacy policy.
Что делать, если пользователь оплатил после истечения ссылки?
Backend должен проверить реальный provider status. Если платеж прошел, создается exception или manual review, а не тихое создание нового paid-заказа без связи с исходным request.
