Интеграция ЮKassa должна связать подтверждённый платёж с заказом: агенты проверяют весь переход

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

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

Готовый модуль стоит проверить раньше собственной разработки. В каталоге ЮKassa есть интеграции для CMS и CRM. Если модуль уже меняет нужные статусы и выдерживает повторы, компании достаточно его настройки и приёмки.

Свой код нужен там, где оплата запускает особое исполнение: создаёт работу в очереди или открывает доступ к заказанному продукту. Тогда CTO принимает этот переход вместе с кнопкой оплаты.

Как связать платёж с заказом? Сервер создаёт заказ с согласованной суммой и сохраняет связь с идентификатором платежа. В metadata ЮKassa позволяет передать номер заказа, но поле не заменяет вашу проверку этой связи.

Условия стоит записать в задаче для ИИ-агента до кода. Агенту нужна проверяемая фраза: чужой платёж, неверная сумма и тестовая оплата не переводят реальный заказ в исполнение.

Цена для сравнения фиксируется при оформлении заказа. Если каталог успел измениться, сервер должен знать, какую стоимость согласовал покупатель. Текущий ценник и сумма старой попытки оплаты не обязаны совпасть.

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

Что будет, если ЮKassa пришлёт уведомление ещё раз? Это штатный случай. Без ответа HTTP 200 сервис продолжает доставку в течение 24 часов от события, по документации на 08.10.2026.

Защита нужна по обе стороны интеграции. Idempotence-Key удерживает повтор одной операции API ЮKassa 24 часа после первого запроса. Он не запрещает вашему коду повторно выдать доступ или поставить заказ в работу.

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

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

Почему мы смотрим дальше кассы? У vibecoding.ru есть открытая история работы машины: на 8 октября 2026 насчитано 7 107 коммитов с 1 июля. Этот счёт показывает способ разработки, а правильность оплаты проверяют отдельные сценарии.

В продаже курса ревью 9 сентября нашло пять проблем. Код мог открыть курс за оплату другого товара, а после сбоя письма доступа не делал повторную отправку. Это интеграция Prodamus, другой платёжный контур.

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

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

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

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

В тестовом магазине проверяется ваш код без выдачи реальных заказов. ЮKassa помечает такие платежи test: true и рекомендует отдельный адрес уведомлений. Тестовые данные не должны открывать боевой доступ.

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

Сколько стоит интеграция ЮKassa? Ответ начинается с границы работы. Установка подходящего модуля и собственный переход с бронями, возвратами и очередью исполнения требуют разного объёма проверки.

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

Мы предлагаем агентную разработку по подписке. Тариф «Один проект» стоит 250 000 ₽ в месяц, по /services на 08.10.2026.

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

Лицензии сторонних сервисов и комиссии ЮKassa считают отдельно. Фикс за месяц не является ценой одной интеграции.

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

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