Оплата в мессенджере: как собрать flow «чат → ссылка → оплата → подтверждение → чек»

Марина из отдела продаж написала мне в пятницу вечером: «Клиент три раза оплатил один заказ. Бухгалтерия в панике. Помогите». Я залез в историю платежей — и точно: три транзакции на одну и ту же сумму за две минуты. Клиент уже грозился жалобой в банк. А магазин детских товаров теряет время на разборки вместо того, чтобы продавать свои 800 заказов в день.

Проблема оказалась типичной: менеджер вручную копировал ссылку из платёжной системы, кидал в Telegram-чат, а дальше — как повезёт. Клиент кликнул, страница загружалась, он подумал, что зависло, и кликнул ещё раз. Потом ещё. Результат: три списания с карты, один недовольный покупатель и бухгалтер с головной болью.

Звучит знакомо? Если вы принимаете оплату через мессенджеры и хоть раз сталкивались с дублями, потерянными платежами или «чек так и не пришёл» — эта статья для вас. Разберём по шагам, как собрать платёжный сценарий, который работает сам и не ломается в самый неподходящий момент.

Из чего состоит платёжный сценарий

Перед тем как лезть в настройки, давайте разберёмся, из чего вообще собирается платёжная цепочка. С виду всё просто: клиент пишет, вы отправляете ссылку, он платит. Но дьявол, как всегда, в деталях. Любой сценарий распадается на пять этапов — и на каждом что-то может сломаться. Хорошая новость: если знать, где искать, можно закрыть все уязвимые места.

Выглядит логично, правда? Но это только схема. В реальности на каждом переходе вас поджидают грабли. Давайте разберём каждый этап подробнее — и сразу посмотрим, что может пойти не так и как это предотвратить.

Этап 1. Чат — где всё начинается (и может сразу закончиться)

Клиент пишет в мессенджер. Казалось бы, что тут сложного? Ответил, уточнил детали, отправил ссылку. Но именно на этом этапе зарождаются будущие проблемы. Помню, как один клиент жаловался: «Заказывал красную коляску, привезли синюю». Оказалось, менеджер вёл диалог в WhatsApp, а потом по памяти заносил данные в CRM. Естественно, перепутал.

Или другая классика: клиент просит доставку на вторник, а менеджер ставит среду, потому что «вторник уже занят». Но забывает согласовать. Клиент ждёт заказ, заказ едет не туда или не тогда — и вот вам возврат, негативный отзыв и потерянное время.

Что должно происходить на этапе чата

Вся переписка с клиентом должна автоматически фиксироваться в CRM — прямо по ходу разговора. Не «потом перенесу», а сейчас. Это первое правило. Второе: если клиент указывает адрес, телефон или email — система должна проверить формат на лету. Неправильный номер? Бот вежливо переспросит. Адрес без города? Уточнит. Это экономит часы разборок потом.

И самое важное: перед тем как отправить ссылку на оплату, бот обязан показать клиенту сводку заказа. Товар, количество, сумма, адрес доставки. «Всё верно? Тогда отправляю ссылку на оплату». Клиент подтверждает — и только тогда генерируется уникальный идентификатор заказа. Этот order_id будет сопровождать платёж на всех этапах — именно по нему вы поймёте, кто и за что заплатил.

Подробнее о том, как настроить бота, чтобы он не терял данные и не путал заказы, мы писали в статье про LLM-ботов в e-commerce.

Этап 2. Ссылка — самое хрупкое звено

Платёжная ссылка — это мост между вашей системой и деньгами клиента. Если мост шаткий, деньги упадут мимо. Или, что ещё хуже, упадут несколько раз.

Помните ту историю с Мариной и тройным платежом? Проблема была в том, что ссылка оказалась многоразовой. Клиент кликнул, страница загружалась долго, он подумал, что зависло. Кликнул ещё раз. Потом ещё. Три успешных списания с карты. Бухгалтерия в шоке, клиент грозится жалобой, бизнес теряет деньги на комиссии за возвраты.

Три правила для платёжных ссылок

Первое: одноразовость. Ссылка должна сработать ровно один раз. После успешной оплаты — всё, она мертва. Большинство эквайеров (ЮKassa, Тинькофф, Stripe) умеют делать одноразовые ссылки, но по умолчанию эта функция часто выключена. Обязательно включите в настройках.

Второе: привязка к order_id. В метаданных платежа всегда должен быть ваш внутренний идентификатор заказа. Не «Оплата от Ивана», а что-то вроде «order_id: 2024-12-23-00847». Через полгода, когда клиент придёт разбираться, только этот ID поможет найти заказ в базе.

Третье: срок жизни. Ссылка не должна жить вечно. Обычно ставят 24 часа. Клиент решил подумать неделю? Пусть напишет заново и получит свежую ссылку. Это не только защита от мошенничества, но и повод вернуться к клиенту: «Вижу, вы не оплатили. Может, что-то не так? Вот новая ссылка».

Idempotency key — техническая страховка

Если работаете с платёжными API напрямую, вам нужно знать про idempotency key. Это такая штука, которая защищает от случайных дублей на уровне сервера.

Представьте: ваш сервер отправил запрос на создание платежа в ЮKassa. Запрос ушёл, но ответ не пришёл — сбой сети. Сервер не знает, создался платёж или нет. Что делать? Отправить запрос ещё раз. Без idempotency key это значит два платежа. С ним — эквайер понимает: «Эй, я уже видел этот запрос», — и возвращает данные первого платежа. Никакой магии, просто грамотная архитектура.

У разных эквайеров он называется по-разному: в ЮKassa это idempotence_key в заголовке запроса, в Stripe — Idempotency-Key, в Тинькофф используют уникальный OrderId. Суть одна: система понимает, что повторный запрос — это не новый платёж, а попытка узнать статус старого.

Подробнее о том, как правильно работать с API платёжных систем (и не только), читайте в нашем гайде по REST API.

Этап 3. Страница оплаты — где решается, заплатят или нет

Клиент кликнул по ссылке. Открылась платёжная форма. И вот тут начинается самое интересное. Если он видит мелкий шрифт, непонятные поля и логотип какой-то левой конторы — конверсия падает. Люди боятся отдавать деньги тем, кого не знают.

Я видел случай, когда магазин «Детский мир» использовал стандартную форму эквайера без брендирования. Клиенты жаловались: «Я заказывал у вас, а платить предлагаете через какой-то непонятный сайт. Это точно не мошенники?». Конверсия была 60%. Как только добавили логотип, фирменные цвета и название магазина — выросла до 89%. Просто потому, что люди увидели знакомый бренд.

Что должно быть на платёжной странице

Во-первых, брендирование. Ваш логотип, ваши цвета, ваше название. Клиент должен понять с первого взгляда, что он платит именно вам. Большинство современных эквайеров позволяют это настроить — не ленитесь.

Во-вторых, чёткое описание того, за что платят. Не «Оплата», а «Оплата заказа #12345 в магазине "Детский мир"». Клиент видит номер своего заказа и успокаивается.

В-третьих, сумма должна быть видна сразу, крупным шрифтом, ещё до того, как человек начнёт вводить данные карты. Никаких сюрпризов в последний момент.

И обязательно — несколько способов оплаты. Карта, СБП, Apple Pay, Google Pay. У каждого свои предпочтения. Кто-то не хочет вводить данные карты и предпочитает СБП. Кто-то привык к Apple Pay. Чем больше опций — тем выше вероятность, что клиент найдёт удобный ему способ.

И да, не забудьте про мобильную версию. 80% оплат из мессенджеров идут с телефона. Если форма не влезает в экран или кнопки слишком мелкие — клиент просто уйдёт.

Когда оплата не прошла

Клиент ввёл данные карты, нажал «Оплатить», и... ошибка. Недостаточно средств. Или карта заблокирована. Или просто технический сбой. Что дальше?

Если ничего — вы теряете клиента. Он закрывает страницу, идёт в другой магазин, забывает про вас. Обидно, но это стандартный сценарий, если систему не настроили.

А правильный сценарий такой: эквайер отправляет webhook об ошибке, ваша система ловит его, и бот тут же пишет клиенту в чат: «Оплата не прошла. Может, попробуете другую карту? Или оплатите через СБП? Вот свежая ссылка». Клиент не остаётся один на один с проблемой — вы возвращаете его обратно в воронку.

Разница огромная. В плохом варианте клиент видит «Ошибка 503» и уходит навсегда. В хорошем — бот через 30 секунд пишет что-то вроде: «Вижу, что-то пошло не так. Давайте попробуем ещё раз? Могу предложить другой способ оплаты». И клиент чувствует заботу, а не брошенность.

Этап 4. Webhook — как система узнаёт, что деньги пришли

Клиент оплатил. Эквайер списал деньги. И теперь должен сообщить вам об этом. Для этого он отправляет webhook — специальный HTTP-запрос на ваш сервер. В нём вся инфа: статус платежа, сумма, order_id, данные плательщика. Ваша задача — принять это уведомление, обновить статус заказа в CRM и написать клиенту. Звучит просто? На бумаге — да. На практике тут тонна подводных камней.

Три правила, которые спасут вас от проблем

Правило первое: отвечайте быстро. Эквайеры не любят ждать. Обычно у вас есть 5-15 секунд на ответ. Если ваш сервер тормозит — webhook будет отправлен повторно. Это значит, что одно и то же уведомление может прийти дважды. Что делать? Принимайте webhook, кидайте задачу в очередь, сразу отвечайте «200 OK». А всю тяжёлую работу — обновление базы, отправку сообщений — делайте асинхронно, после ответа.

Правило второе: проверяйте подпись. Webhook может прислать кто угодно. Злоумышленник может попытаться подделать уведомление и «подтвердить» несуществующий платёж. Все нормальные эквайеры подписывают запросы криптографической подписью — проверяйте её. Это не паранойя, это базовая безопасность.

Правило третье: идемпотентность. Webhook может прийти два раза — из-за таймаута, сбоя сети, чего угодно. Ваша система должна понимать: «Этот платёж я уже видел» — и не обрабатывать его заново. Храните в базе список обработанных payment_id и проверяйте перед каждым действием. Иначе клиент получит два уведомления, а в CRM появится два заказа.

Как написать клиенту, чтобы он остался доволен

Платёж прошёл, статус заказа обновлён. Теперь нужно сообщить клиенту. И вот тут многие спотыкаются. Потому что важен не только сам факт уведомления, но и то, как оно сформулировано.

Сухое «Оплата получена» — это, конечно, лучше чем ничего. Но клиент не чувствует никакой заботы. А вот если написать что-то вроде: «Спасибо! Оплата прошла, заказ #12345 уже взяли в работу. Доставим завтра к 14:00. Отследить можно тут: [ссылка]» — это уже сервис. Клиент видит, что вы контролируете процесс, и расслабляется.

Что ещё стоит добавить? Подтверждение суммы и номера заказа — чтобы клиент убедился, что всё правильно. Следующий шаг — когда ждать доставку, как отследить посылку. Контакт для связи на случай вопросов. И можно ненавязчиво предложить что-то ещё: «Кстати, к этому товару часто берут вот это. Интересно?». Лёгкий апсейл, который не раздражает.

О том, как строить сообщения бота так, чтобы они не бесили, а продавали, мы писали в статье про conversation design для B2B.

Этап 5. Чек — чтобы налоговая не пришла

Последний штрих — электронный чек. По закону 54-ФЗ вы обязаны отправить его покупателю при дистанционной продаже. Не отправили? Штраф от 10 000 рублей для ИП до 40 000 для юрлиц. За каждый чек. Налоговая не шутит.

Хорошая новость: если используете нормальную онлайн-кассу (АТОЛ, Эвотор, Модуль Касса), чек формируется автоматом при получении данных о платеже. Вам нужно только один раз настроить интеграцию — и дальше всё работает само.

Что обязательно должно быть в чеке

Во-первых, нормальное название товара. Не «Товар», а «Конструктор LEGO City 60198». Налоговая проверяет, и если там просто «Товар 1», могут быть вопросы.

Во-вторых, количество и цена. В-третьих, сумма с НДС (если вы его платите). В-четвёртых, email или телефон покупателя — чтобы касса знала, куда отправить. И в-пятых, признак расчёта: приход, возврат или аванс. Без этого чек не пробьётся.

Как отправить чек в мессенджер

В идеале ссылка на чек должна прийти клиенту прямо в чат — туда же, где он делал заказ. Удобно: вся история покупки в одном месте. Технически это делается просто: касса формирует чек, отдаёт URL, ваш бот отправляет эту ссылку клиенту.

Типичный сценарий выглядит так: эквайер шлёт webhook «платёж прошёл» → ваша система передаёт данные в кассу → касса пробивает чек, возвращает ссылку → бот отправляет её клиенту. Весь процесс занимает пару секунд, клиент даже не замечает задержки.

Что может сломаться (спойлер: всё)

Мы прошли весь сценарий от начала до конца. Теперь самое важное: что будет ломаться. Потому что будет — это факт. Любая система даёт сбои. Вопрос не в том, сломается ли, а в том, как быстро вы об этом узнаете и как быстро почините.

Частые косяки и как их отлавливать

Главное правило: логируйте абсолютно всё. Каждый webhook, каждый ответ, каждое отправленное сообщение. Когда (именно когда, а не если) что-то сломается — логи будут вашим единственным способом понять, что пошло не так. Без логов вы слепой котёнок в тёмной комнате.

Подробнее о том, как правильно настроить логирование и мониторинг ботов, чтобы видеть проблемы до того, как о них напишут клиенты, читайте в статье про monitoring AI-ботов.

Как не дать клиенту заплатить дважды

Дубли — это головная боль номер один. Клиент два раза оплатил один заказ. Или webhook пришёл дважды, и в CRM создалось два заказа. Или чек пробили два раза. Бухгалтерия в панике, клиент орёт, вы теряете деньги на комиссиях за возврат. Знакомо?

Защита строится на четырёх уровнях. Каждый отлавливает свой класс проблем. Это не паранойя, это реальность.

Уровень 1: Одноразовая ссылка

Каждая платёжная ссылка должна работать один раз. Клиент оплатил — ссылка умерла. Попытался перейти ещё раз — видит «Оплата уже произведена». Это первый барьер, и он отсекает 90% случайных дублей.

Уровень 2: Idempotency key

Когда ваш сервер создаёт платёж, он передаёт в API эквайера уникальный idempotency key. Даже если запрос уйдёт дважды из-за сбоя — платёж создастся только один. Эквайер поймёт, что это повтор, и вернёт данные первого платежа.

Уровень 3: Дедупликация webhook'ов

Храните в базе список обработанных payment_id. Пришёл webhook? Сначала проверьте: «Я уже видел этот платёж?». Видели — отвечаете «200 OK» и ничего не делаете. Не видели — обрабатываете. Это защищает от повторной отправки webhook'ов.

Уровень 4: Блокировка заказа

Клиент нажал «Оплатить» — заказ блокируется на 15 минут. Нельзя создать новую ссылку для этого же заказа, пока не истечёт таймаут или не придёт подтверждение оплаты. Это отсекает ситуации, когда клиент параллельно открыл несколько ссылок и пытается оплатить по всем.

Четыре уровня — это не избыточность. Это необходимость. Каждый защищает от своего класса проблем, и только вместе они дают надёжность.

Клиент заплатил — а дальше что?

Клиент заплатил, заказ выполнен, на этом всё? Если да — вы оставляете деньги на столе. Потому что момент после оплаты — это золотая возможность укрепить отношения и подтолкнуть к повторной покупке.

Почему это работает? Потому что клиент только что принял решение вам доверять. Он достал карту, ввёл данные, отдал деньги. Он «тёплый». И если вы правильно поработаете с этим моментом, он вернётся.

Что писать клиенту после оплаты

Сразу после оплаты: благодарность и ожидания. Не просто «Оплата получена», а нормальное человеческое сообщение с благодарностью и планом действий. «Спасибо за заказ! Доставим завтра к 14:00. Отследить можно тут: [ссылка]. Вопросы? Пишите, ответим быстро».

Через день-два: проактивный статус. Не ждите, пока клиент спросит «Где мой заказ?». Напишите сами: «Ваш заказ в пути, трек-номер вот: [номер]». Это снижает нагрузку на поддержку и повышает лояльность. Клиент видит, что вы контролируете ситуацию.

Через неделю-две: обратная связь. «Товар дошёл? Как впечатления?» Простой опрос на 1-5 звёзд. Это и метрика NPS, и возможность отловить проблему до того, как она превратится в разгромный отзыв. Если оценка низкая — сразу пишете: «Что пошло не так? Давайте исправим».

Через месяц: персональное предложение. На основе истории покупок предлагаете что-то релевантное. «К вашему конструктору отлично подходит набор дополнительных деталей. Специально для вас — скидка 15%». Не спам, а забота.

О том, как строить retention-стратегии и предсказывать отток, читайте в нашей статье про Customer Success и предсказание churn.

Итоговый чек-лист: запуск платёжного flow

Если вы дочитали до сюда — вы серьёзно настроены. Вот полный чек-лист для запуска надёжного платёжного flow в мессенджере.

Коротко: что важно запомнить

Помните историю про Марину и тройной платёж? После того как мы настроили нормальный сценарий, таких косяков больше не было. Ни одного за полгода. При тех же 800 заказах в день.

Никакой магии. Просто продуманная архитектура: одноразовые ссылки, idempotency keys, дедупликация webhook'ов, логирование всего подряд. По отдельности ничего сложного. Вместе — надёжная система, которая работает сама и не ломается в неподходящий момент.

Да, настройка занимает время. Придётся разобраться с API эквайеров, кассами, webhook'ами. Но оно того стоит. Меньше возвратов, меньше ручной работы, клиенты довольнее, бухгалтерия спокойнее.

И главное: не забывайте, что платёж — это не финал. Это начало. Клиент только что доверил вам деньги. Используйте этот момент, чтобы построить долгосрочные отношения. Именно сейчас решается, вернётся ли он к вам ещё раз.