Оформление и оплата — единственное место магазина, где ошибка стоит прямых денег. Не косметический баг на карточке, а списанные средства без заказа, оплаченный заказ с висящим статусом «ожидает оплаты» или дубль в 1С. Такие дефекты не только теряют выручку, но и подрывают доверие: клиент, у которого списали деньги и не подтвердили заказ, редко возвращается.
Поэтому оформление и оплату тестируют строже всего остального. В статье разберём, какие сценарии проверять в магазине на 1С-Битрикс: успешный путь, отказы и ошибки, двойные оплаты, кассовые чеки по 54-ФЗ, обмен с 1С и граничные случаи. Настройку и проверку торгового функционала мы закрываем услугами автоматизации продаж и склада на 1С.
Коротко
- Деньги теряются не на «счастливом пути», а на отказах, таймаутах, двойных оплатах и рассинхроне с 1С.
- Проверяют идемпотентность: повтор колбэка или двойное нажатие не должны плодить заказы и списания.
- Кассовые чеки по 54-ФЗ обязательны — тестируют формирование, состав, НДС, возвраты.
- Оформление затрагивает почти любая доработка, поэтому сквозной сценарий стоит автоматизировать.
Почему это критичный участок
Оформление заказа и оплата — узел, где сходятся деньги, обязательства и данные. Здесь пересекаются корзина, расчёт стоимости, скидки, доставка, платёжная система, фискализация и обмен с 1С. Любой сбой в этой цепочке имеет финансовые и юридические последствия, в отличие от ошибок в других частях сайта.
Особенность в том, что негативные последствия часто скрыты: клиент оплатил, но заказ не подтвердился — и вы узнаёте об этом из жалобы, а не из отчёта. Именно поэтому тестирование оформления не может ограничиваться беглой проверкой «прошёл заказ — и ладно». Нужен систематический перебор сценариев, особенно тех, где что-то идёт не так.
Что именно тестируем
Полезно заранее очертить границы: оформление и оплата — это не один экран, а цепочка шагов и систем. Тестировать нужно каждое звено и стыки между ними:
- Корзину. Состав, количество, кратность, пересчёт суммы, скидки и промокоды.
- Оформление. Ввод данных, выбор доставки и оплаты, валидацию полей, создание заказа.
- Оплату. Переход в платёжную систему, успех, отказ, возврат на сайт, обработку колбэка.
- Фискализацию. Формирование кассового чека по 54-ФЗ.
- Обмен с 1С. Передачу заказа и синхронизацию статуса оплаты.
Ключевые риски живут именно на стыках: между сайтом и платёжной системой, между оплатой и статусом заказа, между сайтом и 1С. Поэтому тестируют не только каждый шаг, но и переходы между ними, где данные передаются и могут потеряться.
Успешное оформление и оплата
Базовый сценарий — «счастливый путь» — проверяют первым, но воспринимают как минимум, а не как достаточную проверку. Он задаёт эталон, относительно которого проверяют отклонения:
- Сборка корзины. Добавили товары, проверили количество и корректность суммы.
- Оформление. Заполнили данные, выбрали доставку и способ оплаты, создали заказ.
- Оплата. Перешли в платёжную систему, оплатили тестовой картой, вернулись на сайт.
- Подтверждение. Статус заказа сменился на оплаченный, покупатель увидел подтверждение.
- Чек и 1С. Сформировался кассовый чек, заказ ушёл в 1С с верными данными и статусом.
Даже на «счастливом пути» важно проверять не только факт «заказ создан», но и корректность всех данных: сумма совпадает, состав верен, статус обновился, чек пришёл, в 1С попало то же самое. Расхождение хотя бы в одном звене — уже дефект.
Сценарии отказов и ошибок
Здесь начинается настоящее тестирование. Большинство финансовых проблем возникает, когда что-то идёт не по плану, и эти пути надо проверять целенаправленно:
- Отказ оплаты. Карта отклонена — заказ не должен считаться оплаченным, клиент видит понятное сообщение и может повторить.
- Прерванная оплата. Клиент закрыл вкладку на странице банка — заказ остаётся неоплаченным, деньги не списаны.
- Таймаут и потеря колбэка. Платёжная система не смогла достучаться до сайта — статус должен синхронизироваться позже, а не потеряться.
- Оплата с опозданием. Клиент оплатил счёт через час — статус обновляется корректно.
- Возврат средств. Полный и частичный возврат проходит, статусы и чек возврата корректны.
Особенно коварны таймауты и потерянные колбэки: пользователь оплатил, но сайт не получил уведомление вовремя. Система должна уметь дозапросить статус или обработать колбэк позже, а не оставить оплаченный заказ навсегда в статусе ожидания. Надёжность обмена такими уведомлениями мы разбираем в статье про REST, вебхуки и безопасность в Битрикс.
Идемпотентность и двойные оплаты
Один из самых опасных дефектов — задвоение. Оно возникает, когда одно и то же событие обрабатывается дважды: платёжная система прислала колбэк повторно, пользователь дважды нажал «оплатить», или страница успеха перезагрузилась. Без защиты это приводит к двойным спискам, дублям заказов и повторным чекам.
Свойство, которое это предотвращает, называется идемпотентностью: повторная обработка одного платежа не создаёт нового эффекта. Тестируют её прицельно — искусственно повторяют колбэк, дважды жмут кнопку, обновляют страницу подтверждения — и проверяют, что оплата и заказ обработаны ровно один раз. Это тот случай, где «сделать неправильно» нужно проверять специально.
Кассовые чеки по 54-ФЗ
Онлайн-оплата в России требует фискализации: при расчёте формируется кассовый чек по 54-ФЗ. Это не опция, а требование закона, поэтому чеки входят в обязательный набор проверок. Тестируют не только факт формирования, но и корректность содержимого:
| Что проверяем | На что смотрим |
|---|---|
| Формирование чека | Чек создаётся при оплате, уходит покупателю |
| Состав | Позиции, количество, цены и итог совпадают с заказом |
| Ставка НДС | Верная ставка по каждой позиции |
| Признаки расчёта | Способ и предмет расчёта заданы правильно |
| Частичная оплата | Чек аванса и доплаты, если применимо |
| Возврат | Формируется корректный чек возврата |
На 1С-Битрикс фискализация настраивается в связке платёжной системы и кассы, и её обязательно прогоняют на тестовых заказах перед боевым запуском. Ошибка в ставке НДС или в признаке расчёта — это уже не технический баг, а нарушение, поэтому чеки проверяют внимательно.
Обмен заказа с 1С
Оформление не заканчивается на сайте: заказ должен корректно уйти в 1С, а статус оплаты — синхронизироваться между системами. Это отдельная зона тестирования, потому что рассинхрон сайта и учётной системы — частый и дорогой дефект, который мы устраняем в рамках аудита и оптимизации 1С.
Проверяют несколько вещей: заказ доходит до 1С со всем составом, ценами, покупателем, способами оплаты и доставки; статус оплаты синхронизируется в нужную сторону; повторная выгрузка не создаёт дубль; а если обмен упал, заказ не теряется молча, а попадает в очередь на повторную передачу. Отдельно тестируют случай, когда заказ оплачен на сайте, но обмен временно недоступен — данные должны догнать 1С после восстановления. Тонкости работы с данными заказа на уровне ORM полезно понимать, чтобы такие проверки были осмысленными, — об этом статья про D7 и ORM в Битрикс.
Граничные случаи корзины
Граничные случаи — это ситуации на краю нормальной логики, которые чаще всего и ломаются. Их проверяют целенаправленно, потому что на «обычном» заказе они не всплывают:
- Товар закончился в корзине. Позиция стала недоступна, пока лежала в корзине, — оформление должно это отловить.
- Изменилась цена. Цена поменялась между добавлением и оплатой — что видит и платит клиент.
- Промокод на грани условий. Минимальная сумма для скидки, истёкший или исчерпанный промокод.
- Кратность и упаковки. Количество не кратно упаковке — корректная обработка для опта.
- Крайние суммы. Минимальный заказ, очень крупный заказ, пустая корзина.
- Недоступная доставка. Выбранный способ не работает для адреса или состава заказа.
Каждый такой случай — потенциальная ошибка или дыра в логике цен и скидок. Для B2B граничные случаи с кратностью, упаковками и ценами по группам клиентов особенно важны, потому что оптовые заказы крупные и ошибка дорого обходится.
Тестовый режим платёжных систем
Прогонять платёжные сценарии на реальных деньгах не нужно и вредно. Почти все платёжные провайдеры дают песочницу — тестовый режим с отдельными ключами и набором тестовых карт: для успешной оплаты, для отказа, для проверки 3-D Secure, для разных банков. В этом режиме проходит вся логика оплаты и колбэков, но без реального списания.
На 1С-Битрикс платёжный обработчик переключается в тестовый режим в настройках платёжной системы. Это позволяет безопасно прогнать весь набор сценариев — успех, отказ, повтор колбэка, возврат — перед боевым запуском. Обязательный финальный шаг перед продом — контрольная реальная оплата минимальной суммы с последующим возвратом, чтобы убедиться, что боевые ключи и фискализация тоже работают. Стабильность окружения для таких проверок важна, поэтому тестовый стенд стоит держать близким к продакшену — как это устроить, мы разбираем в статье про CI/CD и деплой в Битрикс.
Автоматизация и регрессия
Оформление и оплата затрагиваются почти любой доработкой магазина: поменяли корзину, скидку, доставку — и цепочка оплаты снова под риском. Ручная перепроверка всех сценариев после каждого релиза дорога и ненадёжна, поэтому критичные пути автоматизируют.
Автотесты сквозного сценария — корзина, оформление, оплата в тестовом режиме, проверка статуса и обмена — ловят регрессии до продакшена. Начинают с самого критичного: успешная оплата и главные негативные сценарии, затем расширяют покрытие на граничные случаи. Такие тесты встраивают в процесс деплоя, чтобы ни один релиз не выкатывался без проверки платёжного узла. Полную автоматизацию строят постепенно: даже несколько сквозных автотестов на оплату окупаются первым же пойманным дефектом.
Частые ошибки
- Тестируют только успех. Негативные и граничные сценарии всплывают уже на реальных клиентах.
- Нет проверки идемпотентности. Повтор колбэка или двойное нажатие плодят дубли и двойные списания.
- Игнорируют потерю колбэка. Оплаченный заказ навсегда виснет в статусе ожидания.
- Чеки не проверяют. Формируются с ошибкой в НДС или признаке расчёта — нарушение 54-ФЗ.
- Не тестируют обмен с 1С. Заказ на сайте есть, в учёте нет или задвоен.
- Пропускают граничные случаи. Кончившийся товар, изменённая цена, кратность ломают заказ.
- Проверяют вручную после каждого релиза. Без автотестов регрессии в оплате повторяются.
Чек-лист тестирования
- Счастливый путь пройден. Заказ, оплата, чек и обмен с 1С корректны, все данные совпадают.
- Отказы проверены. Отклонённая, прерванная и опоздавшая оплата обрабатываются верно.
- Идемпотентность есть. Повтор колбэка и двойное нажатие не создают дублей и списаний.
- Колбэки надёжны. Потерянное уведомление об оплате догоняет статус, а не теряется.
- Чеки 54-ФЗ корректны. Состав, НДС, признаки расчёта, возвраты проверены на тестовых заказах.
- Обмен с 1С надёжен. Заказ доходит без дублей, статус синхронизируется, сбой не теряет заказ.
- Граничные случаи покрыты. Кончившийся товар, смена цены, промокоды, кратность, крайние суммы.
- Ключевое автоматизировано. Сквозные автотесты оплаты встроены в деплой.
Вывод
Оформление и оплата — участок, где ошибка стоит прямых денег и доверия клиента, поэтому тестируют его строже всего остального. Ключевой принцип: «счастливый путь» — это минимум, а не проверка. Реальные потери живут на отказах, таймаутах, двойных оплатах, некорректных чеках и рассинхроне с 1С — именно эти сценарии нужно перебирать целенаправленно.
Соберите набор проверок из успешного пути, негативных и граничных сценариев, идемпотентности, чеков 54-ФЗ и обмена с 1С, прогоняйте их в тестовом режиме платёжной системы и автоматизируйте критичное. Тогда каждый релиз не будет лотереей, а платёжный узел магазина на 1С-Битрикс останется надёжным — а именно от него зависит, дойдут ли деньги и доверие клиента до вас.
