Платёжная ссылка в звонке с ИИ: проверить заказ и получателя

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

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

Условный звонок вторника: клиент подтверждает три позиции, ИИ-продавец обещает ссылку на оплату, менеджер переводит заказ на новый этап. Через минуту в чате появляется ссылка. Вопрос не в том, как аккуратно она выглядит, а в том, из какого заказа она родилась, кто подтвердил получателя и что считается оплатой.

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

Проверка перед отправкой: заказ, плательщик, сумма и срок

Перед отправкой сотрудник открывает карточку, где рядом стоят номер заказа, версия суммы, получатель, плательщик, домен ссылки, срок действия и состояние. Слова ИИ-продавца в стенограмме — контекст, а не доказательство. Если карточка не показывает, из какого заказа взята ссылка, отправка останавливается: красивая фраза не заменяет происхождение.

Условный заказ № 2417 на три позиции, сумма 18 400 ₽, получатель — условное ООО «Ромашка», плательщик — условный ИП Иванов. В чате лежит ссылка из прошлого заказа № 2388. Она открывается, домен знакомый, сумма похожа. Сотрудник не отправляет её повторно: в карточке нет привязки к новой версии заказа, а получатель в ссылке относится к другой организации. Он создаёт новую ссылку после подтверждения заказа и фиксирует причину отказа.

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

Платёжная ссылка как рабочий объект с журналом происхождения

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

Ключевые поля не редактируют «для удобства». Если сотрудник меняет сумму, получателя или срок, появляется новая версия объекта и, как правило, новая ссылка. Старая версия остаётся в журнале с причиной замены. Это не бюрократия ради журнала: именно так можно понять, почему клиент оплатил одну сумму, а в заказе стоит другая.

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

Старая ссылка из закрытого заказа

Условный клиент возвращается через девятнадцать дней. Заказ № 2388 давно закрыт, но в переписке осталась ссылка. ИИ-продавец находит её в истории, видит знакомый домен и предлагает отправить ещё раз: клиент же сам вернулся. Сотрудник открывает карточку и видит, что ссылка привязана к старой версии заказа, а срок действия истёк. Оплата по ней либо не пройдёт, либо создаст платёж, который потом придётся разбирать вручную.

«Открывается» не значит «актуальна». Страница может показать остаток или форму, но это не делает ссылку частью нового обязательства. В документации Stripe описан конструктор платёжных ссылок и связанные с ним настройки; конкретный набор ограничений зависит от вашей системы и договорённостей с провайдером. Читать это как разрешение отправлять старую ссылку нельзя. Документация Stripe по платёжным ссылкам полезна как ориентир по вопросам, которые стоит задать уполномоченному сотруднику: что именно связывает ссылку с заказом, как задан срок и что считается событием оплаты.

Рекомендация для проекта: ИИ-продавец не переотправляет ссылку из истории вообще. Он может сказать, что передал задачу сотруднику, а сотрудник создаёт новый объект после подтверждения заказа. Если платёжная система позволяет ограничить срок жизни ссылки, это стоит обсудить с теми, кто отвечает за платёжный контур; настройка и проверка остаются за уполномоченным сотрудником.

Сумма, собранная из разных источников

Условный заказ № 2510: четыре позиции, одна замена, доставка. В CRM сумма 12 300 ₽, в ссылке 11 900 ₽, клиент в звонке называет 12 000 ₽. ИИ-продавец слышит последнюю цифру и предлагает «округлить». Сотрудник останавливает сценарий: в карточке ссылки стоит снимок суммы на момент создания, а заказ уже изменился. Ни одна из трёх цифр не становится истиной только потому, что прозвучала в разговоре.

Сумма в ссылке не обязана меняться сама. Это снимок, а не живой пересчёт. Если заказ изменился, нужен новый объект с новой версией и понятной причиной: замена позиции, уточнение доставки, исправление количества. Старую ссылку блокируют или помечают недействительной, если это позволяет платёжный контур. Если не позволяет, сотрудник всё равно не отправляет её как актуальную.

Не просите клиента «доплатить разницу» в звонке, пока уполномоченный сотрудник не сверил заказ и применимые документы. ИИ-продавец может зафиксировать вопрос и передать задачу, но не должен превращать платёжную ссылку в инструмент переговоров о цене. Финансовые и налоговые последствия таких решений — не зона агента.

Получатель и плательщик: совпадение не по звучанию

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

В документации Microsoft по созданию и обработке заказов описаны атрибуты заказа: клиент, позиции, суммы и связанные действия. Это полезно как напоминание, что заказ и платёжный инструмент — разные слои. Сам документ не доказывает наличие функций в вашей CRM и не отвечает на вопрос, можно ли принять платёж от другого лица. Документация Microsoft по заказам помогает сформулировать, какие поля заказа должны быть зафиксированы до создания ссылки, но решение остаётся за уполномоченным сотрудником.

Совпадение по звучанию — не совпадение. Название компании может отличаться на одну букву, ИП и ООО — это разные субъекты, а «брат директора» не становится плательщиком по умолчанию. Если получатель и плательщик разные, это не автоматический запрет, а повод для проверки по применимым документам. Агент не решает этот вопрос и не просит клиента «подтвердить, что всё нормально».

Код из сообщения: остановка, а не подсказка

Клиент говорит: «Мне пришёл код 1234, записывайте». ИИ-продавец не должен ни записывать, ни повторять, ни просить назвать код ещё раз. Агент не получает номера карт, CVV и одноразовые коды. Это не элемент заказа и не способ «подтвердить оплату». Код — секрет, который не должен попадать в CRM, стенограмму, заметку или контекст модели.

На сайте Банка России есть раздел об информационной безопасности, где собраны материалы о типовых рисках и правилах защиты. Материалы Банка России по информационной безопасности стоит использовать как повод проверить применимые документы банка и внутренние правила, а не как инструкцию, которую агент пересказывает клиенту. Конкретный порядок действий определяет уполномоченный сотрудник; в статье не устанавливаются обязанности, сроки или условия безопасности оборудования.

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

Статус не пришёл: пауза, сверка, а не победный рапорт

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

Успех определяется доверенным событием оплаты или учёта, а не словами клиента и не открытием страницы. Если статус не пришёл, правильная реакция — пауза. ИИ-продавец может сказать: «Передал сотруднику, он проверит поступление». Он не говорит «оплачено», «заказ подтверждён» или «ссылка сработала», пока не получил результат от разрешённого инструмента.

Повторная оплата после тайм-аута

Условный клиент нажал «оплатить», страница долго думала, он нажал ещё раз. В платёжной системе две попытки, в заказе одна сумма, в чате паника. ИИ-продавец не просит оплатить ещё раз «на всякий случай» и не обещает автоматический возврат. Сотрудник открывает карточку ссылки, смотрит попытки и события, затем действует по применимым документам и правилам платёжного контура.

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

Интерфейс сотрудника: очередь ссылок, причины блокировки и след действий

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

В агентской CRM CRM есть поиск клиентов, подготовка карточек, согласованные сообщения и звонки; изменение этапа, суммы и ответственного согласует сотрудник. В проекте к этому можно добавить карточку ссылки, но сама оплата остаётся в платёжной системе. Если в демонстрации показывают «оплату в CRM», стоит уточнить, что именно там хранится: идентификатор, статус, событие или только текст сообщения.

Запреты должны быть видимы, а не спрятаны в инструкции. В интерфейсе полезны понятные состояния: «ссылка из старого заказа», «сумма не совпадает», «получатель требует проверки», «код в разговоре — стоп», «статус не получен». Сотрудник видит, почему кнопка «отправить» неактивна, и может передать задачу дальше. ИИ-продавец видит только разрешённые действия и не получает права менять сумму или подтверждать платёж.

Роль ИИ-продавца: произнести, зафиксировать, передать

Фонекс описан как ИИ-продавец в звонках по согласованному сценарию: он фиксирует интерес и передаёт задачу менеджеру. В платёжном маршруте этого недостаточно, чтобы считать оплату подтверждённой. Агент может произнести согласованную фразу, зафиксировать запрос и передать задачу. Создание ссылки, проверка получателя и признание оплаты — отдельные действия с отдельными правами.

Если в проекте настроен инструмент, который возвращает ссылку, он должен возвращать идентификатор и состояние, а не свободный текст «вот ссылка, отправляйте». Фраза агента строится из результата инструмента. Если инструмент не ответил, агент говорит: «Передал сотруднику». Он не придумывает домен, не собирает ссылку из частей и не повторяет старую из истории.

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

Трудные исключения: частичная оплата, несколько плательщиков, смена валюты

Частичная оплата — не повод делать ссылку «на глаз». Если заказ допускает часть суммы, ссылка привязывается к конкретной части и версии заказа, а остаток фиксируется отдельно. Сотрудник подтверждает, что такая схема допустима по применимым документам. ИИ-продавец не делит сумму сам и не обещает, что «остальное потом».

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

Смена валюты, пересчёт и округление — не действия ИИ-продавца. Если валюта ссылки не совпадает с валютой заказа, это стоп-сигнал для сотрудника. Рекомендация: в карточке ссылки хранить валюту заказа и валюту платежа отдельными полями, чтобы расхождение было видно до отправки, а не после звонка.

Тесты, которые ломают демонстрацию

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

Отдельно проверяют подмену домена: ссылка выглядит похоже, но ведёт не туда. Агент не «исправляет» домен в тексте и не просит клиента «перейти по той, что выше». Сотрудник сверяет идентификатор и домен с разрешённым источником. Тест считается пройденным, когда система не просто показала ошибку, а объяснила, кто и что должен сделать дальше.

Практикум: разбор одного звонка по шагам

Условный звонок в 10:12: заказ № 77-К на две позиции, сумма 7 450 ₽, получатель — условное ООО «Вектор», плательщик — условный ИП Соколов. Ссылка создана в 10:12 и действует до 10:42. Клиент звонит в 10:50 и говорит, что оплатил, но статус не пришёл. В чате — скриншот страницы. Сотрудник не начинает с вопроса «а вы точно оплатили?». Он восстанавливает маршрут.

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

Как проверить маршрут оплаты до следующего клиентского звонка

Возьмите разрешённый тестовый заказ и получите ссылку через предусмотренную платёжную систему. Проверьте, может ли сотрудник без догадок восстановить заказ, сумму, валюту и получателя. Затем измените одну деталь: завершите срок действия, поменяйте принятую версию заказа или задержите уведомление. Ответ агента должен следовать изменившемуся состоянию, а не прежнему тексту разговора.

Для испытаний используйте тестовый режим провайдера и вымышленные данные. Такой тест проверяет подготовленный маршрут и интерфейс, но не доказывает, что рабочий эквайринг, учёт, возвраты и чеки полностью готовы. Эти участки принимают отдельно по фактической конфигурации компании. Публичная инструкция Stripe описывает собственный механизм ссылок, а не гарантированную интеграцию Фонекса с оплатой.

Покупателю нужно знать, что ему предлагают оплатить и где искать подтверждение. Агенту достаточно помогать с этим объяснением и передавать точную неопределённость человеку. Платёжные секреты в разговоре для такой задачи не требуются. Начните с проверки одного полного маршрута: подтверждённый заказ, разрешённая ссылка, понятное сообщение и доверенное состояние платежа.

Соседний вопрос разобран отдельно: Частичная оплата в CRM: почему агенту рано закрывать всю продажу. Здесь основной предмет — проверка происхождения ссылки и состояния платежа, запрет запроса кодов; не финансовый эквайринг и не форма заявки.