Українська
Հայերեն
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
В фокусе статьи
Исходная задача: не терять контекст заявки после оплаты
Услуга начинается с формы на Tilda, но оплата и дальнейшая работа должны оставаться привязанными к одной CRM-сделке.
В типовом сервисном сценарии менеджер получает заявку из Tilda, согласует услугу и отправляет клиенту ссылку на предоплату. Если ссылка создается вручную без CRM id, команда теряет связь между платежом, услугой и ответственным сотрудником.
В кейсе CRM создает платежный запрос с id сделки, услугой, суммой, валютой и сроком действия. Клиент получает ссылку только после фиксации этих данных, поэтому оплата не становится обезличенной суммой в выписке.
- сохранять CRM deal id в payment metadata;
- не позволять менеджеру менять сумму после создания ссылки без новой версии запроса;
- задавать срок действия и понятное назначение платежа;
- сводить персональные данные в payment record к необходимому минимуму.
Решение: CRM меняет этап только после проверенного события
Статус сделки не зависит от скриншота или клика по success page: его меняет только backend после проверки оплаты.
Webhook или server-side status check поступает в backend, где проверяются идентификаторы, сумма, валюта и подпись. Только затем CRM-сделка переходит в этап подтвержденной предоплаты.
Повторные события безопасно игнорируются на уровне бизнес-действия. При неуспехе или истечении ссылки заявка остается в понятном этапе, а менеджер может отправить новую ссылку без потери истории.
- не открывать доступ к услуге по frontend-сигналу;
- делать webhook-переход идемпотентным;
- хранить дату подтверждения и внешний payment id в CRM;
- отдельно обрабатывать expired, failed, pending и paid.
Контроль после запуска: выдача услуги и возврат
Подтвержденный платеж должен включать правило оказания услуги, уведомление и понятный путь для возврата.
После подтверждения можно создать задачу, открыть доступ, подтвердить запись или отправить клиенту уведомление. Конкретное действие должно быть описано в бизнес-правиле, а не зависеть от ручной интерпретации менеджера.
Если услуга отменяется, возврат регистрируется отдельным событием с причиной и связью с исходной сделкой. Это сохраняет прозрачную историю для поддержки, учета и клиента.
- фиксировать правило выдачи услуги после paid;
- не смешивать предоплату, доплату и возврат в одном поле CRM;
- сохранять источник, дату и ответственного за ручную корректировку;
- проверять в сверке ссылки с истекшим сроком и pending-операции.
FAQ
Можно ли отправлять ссылку на оплату из Tilda без CRM?
Технически можно, но для управляемого процесса лучше создавать ссылку из CRM или backend с привязкой к заявке, услуге и ответственному сотруднику.
Когда переводить сделку в оплаченный этап?
Только после server-side проверки платежа или корректно обработанного webhook. Страница успеха и скриншот не подтверждают финальный статус.
Как оформить отмену услуги?
Зафиксировать отмену и возврат отдельными событиями, связанными с исходной сделкой и платежом. История предоплаты должна сохраниться.
