Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
CRM не должна быть платежным провайдером
Bitrix24, amoCRM или Kommo удобны для менеджеров, но финальный платежный статус должен приходить из server-side проверки.
Частая ошибка - считать, что CRM сама может быть источником истины по оплате. Менеджер создал сделку, отправил ссылку, клиент перешел на оплату, но финальное состояние должно подтверждаться backend: через проверенный webhook, provider reference и повторную проверку статуса.
CRM в этом сценарии хранит бизнес-контекст: сделку, счет, клиента, менеджера, комментарии и задачи. Платежный слой хранит попытку оплаты, статус, сумму, валюту, время, request id и техническую историю. Так поддержка видит картину целиком, а бухгалтерия получает пригодные данные для сверки.
- не обновлять сделку только по redirect клиента;
- хранить provider reference рядом с CRM invoice/deal id;
- разделять created, pending, paid, failed, expired и refunded;
- логировать повторную отправку payment link менеджером.
Как проектировать статусы сделок и счетов
CRM-статусы должны помогать менеджеру, а не повторять все технические статусы провайдера один в один.
Для CRM полезнее нормализованный набор статусов: ожидает оплаты, оплачен, ошибка оплаты, истек срок, нужен ручной review, частичный возврат, полный возврат. Внутри backend может хранить больше технических деталей, но менеджеру нужен короткий список действий.
Отдельно нужно описать правила переходов. Например, failed не должен закрывать счет навсегда, если клиент может повторить попытку. Pending не должен отправлять товар или услугу. Refunded не должен удалять историю оплаты из сделки.
- связать payment attempt с конкретным счетом или сделкой;
- создавать задачу менеджеру только для исключений;
- не перетирать paid случайным старым webhook;
- показывать paidAt, amount, currency и provider reference.
Что учитывать в webhooks и повторных попытках
CRM API может отвечать с задержками и лимитами, поэтому синхронизация оплаты должна быть идемпотентной и повторяемой.
Webhook от платежного провайдера может прийти повторно, прийти раньше redirect или прийти в момент, когда CRM API временно недоступен. Поэтому обработчик должен проверять подпись, сохранять событие, применять idempotency key и обновлять CRM через контролируемую очередь.
Если обновление CRM не прошло, платеж нельзя терять. Нужно оставить внутренний paid-статус, записать ошибку синхронизации, повторить операцию и показать оператору исключение только после нескольких неуспешных попыток.
- проверять подпись или server-side статус провайдера;
- делать CRM update идемпотентным;
- повторять временные ошибки API;
- хранить audit trail по ручным исправлениям.
FAQ
Можно ли обновлять сделку в CRM сразу после перехода клиента на success page?
Нет. Success page полезна для клиента, но CRM лучше обновлять после server-side проверки платежа или доверенного webhook. Redirect может быть закрыт, повторен или открыт без финального статуса.
Что делать, если CRM API недоступен во время оплаты?
Платежный backend должен сохранить финальный статус, поставить CRM-синхронизацию в retry и показать исключение оператору, если повторные попытки не прошли.
Нужно ли менеджеру видеть все технические статусы провайдера?
Обычно нет. Менеджеру нужен нормализованный статус и понятное действие. Технические детали лучше хранить в audit trail и платежной карточке.
