Оформление заказа на сайте проверяют до оплаты: агенты связывают поля, доставку и итог заказа

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

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

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

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

Смена города проверяет и выбранный пункт. Условный покупатель выбрал пункт в одном городе, вернулся к адресу и указал другой. Приёмка требует сбросить неприменимый выбор и предложить доступные пункты. WooCommerce связывает доступные способы с зоной адреса; в своей форме эту связь тоже надо проверить. Сохранённый старый пункт рядом с новым городом означает отказ в приёмке.

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

Проверки полей формы согласуют на стороне браузера и сервера.

Возьмём учебную корзину: товары стоят 2 400 ₽, скидка составляет 400 ₽. Самовывоз бесплатный, курьер к первому условному адресу стоит 350 ₽, к другому стоит 550 ₽. Это придуманные данные для проверки, не цены перевозчика. Они нужны, чтобы принимающий заранее знал итог каждого перехода.

Покупатель выбрал курьера и увидел 2 350 ₽, затем сменил адрес. Пока новый расчёт не пришёл, прежняя сумма не должна выглядеть подтверждённой. Когда пришло 2 550 ₽, покажите изменение и дайте покупателю подтвердить новый итог. Поздний ответ для старого адреса не должен заменить результат для нового.

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

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

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

Различайте черновик, созданный неоплаченный заказ и успешную оплату. Например, API оформления WooCommerce возвращает отдельный черновик. Его существование не доказывает, что покупатель подтвердил заказ. Дооплатная приёмка заканчивается согласованной записью заказа и понятным следующим действием; статус «оплачен» ей не нужен.

На vibecoding.ru инженер ведёт машину агентов. На публичной странице, где мы строим и проверяем сайт, на 7 октября показано 7 063 коммита за 98 дней, с 1 июля по 7 октября 2026. Это объём работы машины. Он не доказывает качество отдельной формы; для формы нужно собственное ревью.

В ревью покупки курса 9 сентября нашли пять проблем в полной цепочке. Для этой статьи важны два стыка до оплаты: цена считалась на витрине и сервере отдельно, а сбой сервиса выглядел как ошибка покупателя. Форма могла выглядеть готовой, хотя её соседние части требовали проверки.

Цена получила проверку согласованности двух расчётов; сообщение о сбое дополнили понятным способом обратиться за помощью. Этот урок переносится на доставку: одинаковое поле «итог» не гарантирует одинаковую сумму во всех частях заказа. Переносится правило проверки, а не кейс магазина: у курса нет физической корзины, и прирост конверсии мы здесь не измеряли.

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

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

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

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

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

Принимать удобнее на версии для проверки и на вымышленных данных. Покажите весь путь на телефоне, затем откройте созданный заказ со стороны магазина. Сравните состав, контакт, адрес или пункт, стоимость доставки, скидку и итог. Если экран и запись расходятся, работа не принята, даже когда агент предъявил успешные проверки своего кода.

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

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

Перед распродажей доработку интернет-магазина принимают по проверенному заказу, оплате и остаткам.

Когда доставка снова не выбирается, восстановите последовательность на учебных данных. Добавьте её в приёмку, исправьте причину и проверьте повтор. Так наблюдение кормит правила следующей задачи. Если ошибка только попала в отчёт и больше ничего не изменилось, оформление осталось без защиты от повторения.

Если правки нужны регулярно, на странице разработки есть подписка «Один проект»: 250 000 ₽ в месяц, один продукт и один поток работы. Цена проверена 7 октября 2026. Это цена подписки, а не оценка разработки этой формы. Поля, доставка, расчёт итогов и создание заказа могут составить её задачу; подключение платёжного шлюза согласуют отдельно.

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

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

2. Проверяйте смену выбора, неизвестную стоимость и повтор после потерянного ответа.

3. Дайте агенту учебные данные и ожидаемый результат; работу принимает инженер.

4. После выпуска превращайте найденный сбой в новый сценарий и проверку.