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

Чтобы подключить оплату на сайт, не всегда нужна разработка. Для готовой CMS есть платёжные модули; Robokassa описывает отдельно модуль и API для собственного сайта.

Своя цепочка появляется там, где после оплаты нужно открыть кабинет или услугу. Банк проводит платёж, а ваш сайт связывает его с заказом и выдаёт покупку.

Страница «Спасибо» ничего не доказывает. Покупатель может закрыть её, а уведомление об оплате прийти позже; сервер должен закончить продажу без открытого браузера.

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

В записи от 9 сентября 2026 разобраны пять исправлений после такого ревью. Среди них проверка товара, повтор письма после сбоя и согласование цены.

Это найденные риски, а не пять случившихся потерь. Нам важен способ проверки: другой агент читает, как звенья связаны между собой, и ищет незаданные условия.

Тесты отвечают только на вопросы, которые в них заложили. Если автор проверил правильный товар, тест не проверит оплату другого товара сам по себе.

Платёжный сервис тоже не знает всех правил вашего продукта. В документации ЮKassa отдельно описаны подлинность уведомления и актуальный статус; проверять заказ и права покупателя должен ваш код.

Ошибки на стыках требуют проверки последствий. «Доступ уже выдан» и «письмо отправлено» должны различаться, иначе повтор уведомления не восстановит потерянное письмо.

Дважды проверить оплату не означает два раза нажать кнопку. Первая проверка прогоняет сценарии, вторая ищет правила, которые автор кода и тестов забыли.

Автору недостаточно поручить «подключить оплату». Задача для агента должна назвать результат для покупателя и поведение при сбое; для денег эти условия разбирают отдельно.

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

Другая модель тоже ошибается. Её замечания инженер разбирает по коду и документации; найденный дефект превращается в новый проверяемый сценарий.

Так замыкается проверка. Повторное уведомление должно оставить один результат покупки, а сбой письма должен позволить восстановить отправку без нового списания.

Приёмка должна проверять и покупателя, который закрыл браузер после оплаты. Если доступ выдаётся только со страницы «Спасибо», продажа зависит от лишнего действия клиента.

Рекуррентные платежи означают повторные списания с согласованного способа оплаты. ЮKassa описывает отдельно его сохранение, последующие платежи и отказ пользователя от них.

У разовой покупки проверяют получение товара, у подписки добавляется следующий платёж. Заказчику нужно определить период оплаты и что увидит клиент после отказа от продления.

Кнопка «Отменить» должна менять работу списаний. Если интерфейс показал отмену, а фоновая задача продолжает создавать платежи, проверка кнопки прошла, проверка подписки нет.

Тестовая касса позволяет проверить платёж без перевода денег. ЮKassa прямо разделяет тестовый режим и реальные операции; успешный тест не подтверждает настройки рабочего магазина.

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

Правила для агентов задают эту границу, а ответственность за ошибки остаётся у компании. Повторное ревью даёт основания для решения, не снимает его с человека.

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

Для готового магазина с подходящим модулем достаточно настройки и проверки покупки. Если нужны свой кабинет и правила доступа, каждое звено должно войти в состав работ.

Отдельно договоритесь, кто увидит сбой после запуска. Запись «оплачено, письмо не отправлено» должна попасть тому, кто восстановит покупку, иначе ошибка останется у клиента.

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

В подписке «Один проект» оплата, письмо доступа и кабинет могут идти как связанные задачи одного продукта. На 7 октября 2026 тариф стоит 250 000 ₽ в месяц; одна задача выполняется, следующая ждёт в очереди.

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

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