Разработка для финтеха с агентами: где ошибка стоит денег, проверок становится больше, а не меньше

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

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

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

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

Ревью другой моделью привело к пяти исправлениям в коде 9 сентября 2026 года. Проверку дополнили сопоставлением товара. Покупка другой услуги перестала быть основанием открыть курс.

Запись описывает потенциальные последствия, а не потери покупателей. Ответственность за ошибки ИИ разобрана отдельно. Здесь важен способ проверить денежное правило до выпуска.

Успешная оплата показывает лишь один путь. Документация ЮKassa, проверенная 7 октября 2026 года, различает успешный платёж, отмену и ожидание подтверждения. Продукт должен понимать, какой из этих статусов разрешает его действие.

Повтор уведомления тоже относится к рабочему сценарию. ЮKassa повторяет доставку, если не получает подтверждение. Stripe предупреждает о повторах и не гарантирует порядок доставки. Команда проверяет поведение своего провайдера по его документации.

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

Ключ повторного запроса к кассе и защита своей выдачи решают разные задачи. В ЮKassa одинаковый ключ с теми же данными защищает повтор запроса в ограниченном временном окне. Он не мешает вашему приложению второй раз начислить доступ.

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

Количество тестов описывает объём проверки, но не доказывает правильность денежного правила. На странице /open 7 октября 2026 года указано 2 685 тестов на каждом пуше плюс ревью. Это контур выпуска всего сайта, не число проверок оплаты и не процент финансовой точности.

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

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

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

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

Песочница проверяет логику без перевода денег. У тестового магазина ЮKassa отдельные ключи, а платёж отмечен test=true. Боевой обработчик не должен принимать такой платёж за настоящую покупку.

Переход в бой не сводится к замене ключа. Команда проверяет настройки настоящего магазина, доставку уведомлений и весь путь от оплаты до учёта. Не все способы оплаты доступны в тестовом магазине ЮKassa, поэтому песочница не заменяет проверку выбранного боевого способа.

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

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

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

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

Своего клиентского кейса в финтехе у нас нет. Наш пример касается оплаты курса на vibecoding.ru, где инженер ведёт машину агентов. Он показывает механизм проверки и не обещает тот же срок или стоимость для банка.

На /services тариф «Один проект» стоит 250 000 ₽ в месяц на 7 октября 2026 года. Его можно обсуждать для беклога финтех-продукта с тестами на деньги до выпуска. Это цена подписки на работу с беклогом, а не смета запуска платёжной системы.

Архитектурные решения и ночные дежурства подписка не берёт. На стороне продукта нужны инженер, который принимает денежную правку, и ответственный за эксплуатацию. Финансовые решения и юридические требования эта статья не определяет.

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

2. Примите повторы, отказы и возвраты отдельно от успешной оплаты. Смотрите на итог в учёте, а не только на ответ сервера.

3. Разделите тестовую кассу и боевые права. Выпуск разрешает принимающий инженер.

4. Сохраните историю операции и подготовьте сверку с провайдером. Исправление кода не отменяет уже проведённый платёж.

5. Начните пилот с одного денежного пути. Результатом должны стать код, проверочные сценарии и доказательства приёмки.