Учебная оплата в локальной песочнице

Оглавление серии

Платёжный метод связывает оформление с результатом оплаты, но кнопка «Заказать» сама по себе не подтверждает поступление денег. Для «Полки» нужны два учебных сценария: заказ ожидает ручного решения и локальный simulator возвращает success или failure. Ни банковских реквизитов, ни настоящих карт, ни аккаунта внешнего provider в этой серии нет.

После урока вы сможете отличить ожидание от подтверждённого учебного результата и найти соответствующее состояние Order. Мы не устанавливали payment extensions и не оформляли orders. Все ответы являются ожидаемыми. Основной путь можно изучить через встроенный BACS с пустыми реквизитами; Dummy — отдельное опциональное расширение для вашей будущей лаборатории.

BACS показывает ручное ожидание

В WooCommerce Settings → Payments найдите offline payments и Direct Bank Transfer. Включите метод, затем откройте Manage. Title замените на «Учебное ожидание». Description и Instructions должны прямо сообщать: «Локальная лаборатория. Не переводите деньги. Подтверждение выполняется вручную для изучения состояний». Account details оставьте пустым.

Название интерфейса не меняет техническую природу gateway. BACS сохраняет заказ в состоянии On hold, ожидая подтверждения вне checkout. В реальном магазине оператор проверяет фактическое поступление по правилам выбранного банковского процесса. В нашей лаборатории никакого поступления нет: изменяя статус позже, мы моделируем результат и не называем его настоящей оплатой.

Официальное поведение описано в Direct Bank Transfer. Мы используем его как иллюстрацию ожидания именно потому, что он не должен автоматически объявлять платёж успешным. Если после BACS заказ сразу Completed, проверьте дополнительные plugins или изменения, которые вмешиваются в состояние.

Guard допускает bacs только в local environment и скрывает остальные реальные способы. Он не подключается к банку и не проверяет деньги. Такое ограничение помогает не увидеть случайно активный gateway из чужого окружения, но не заменяет отдельную лабораторию. До первого checkout убедитесь, что на экране нет настоящих payment methods.

Dummy моделирует успех и отказ

Официальный WooCommerce Dummy Payments Gateway предназначен для разработки и объявляет поддержку block-based checkout. В прочитанном plugin header версия 2.0.0; при этом Tested up to указан 6.6. Следовательно, совместимость с выбранной WordPress/WooCommerce линией нельзя объявить подтверждённой без вашего локального запуска. Источник — репозиторий Dummy.

Репозиторий содержит build instructions: исходники требуют подготовленной сборки, а не простого копирования одного PHP-файла. Мы не включаем чужой готовый binary plugin в архив и не выполняем dependency installation. Если выбираете этот опыт, используйте официальный источник, зафиксируйте конкретный commit/version и следуйте его instructions в собственной лаборатории.

После установки найдите Dummy в Payments, задайте понятный title «Учебная оплата без денег» и Payment result success. Код официального gateway вызывает payment_complete для обычного успешного заказа. Для failure он переводит order в failed и сообщает ошибку. Эти свойства прочитаны по официальному классу; наш курс не выдаёт их за наблюдённые транзакции.

Если метод не виден в Checkout Block, не переключайтесь сразу на classic checkout. Сначала проверьте, собран ли plugin с Blocks integration, enabled setting, разрешение показа пользователю и совместимость текущей версии. Пустой payment section сообщает о конфигурации, а не о том, что нужно ввести настоящую карту.

Сценарии имеют разные ожидаемые состояния

Файл specs/payment-cases.csv связывает метод, настройку и ожидаемый результат.

method,setting,expected_status,external_money
bacs,Учебное ожидание; пустые Account details,on-hold,none
dummy,success,completed for all virtual downloadable,none
dummy,failure,failed,none

Для BACS ожидается on-hold. Для Dummy success при всех virtual/downloadable items ожидается completed. Для Dummy failure — failed. Последние результаты зависят также от состава заказа и поведения выбранного gateway. Если в cart есть physical Product, успешная оплата обычно может оставить Processing для исполнения, а не автоматически закончить заказ.

В лаборатории downloads ещё не привязаны. Поэтому Completed не доказывает, что файл уже выдаётся корректно. Состояние оплаты, выполнение заказа и существование downloadable permissions рассматриваются отдельно. Один «успешный» экран не подтверждает всю цепочку получения материала; это проверим после настройки файлов.

Не повторяйте payment_complete вручную для уже завершённого order только ради второго сообщения. Повторное действие может запустить notifications или integrations. Для каждого нового опыта создавайте отдельный учебный order, сохраняя его ID и выбранный scenario. Тогда success и failure не смешаются в истории одного объекта без объяснения.

Возвращённая страница не является источником истины

После checkout browser может увидеть order received page. Она сообщает результат текущего процесса, но заказ и его notes остаются серверным состоянием. Если закрыть окно до возвращения, Order не обязан исчезнуть. Если обновить страницу, это не должно создавать вторую покупку автоматически. Именно поэтому payment integration рассматривает идентификатор заказа и повторные callbacks отдельно от navigation браузера.

Откройте Orders в admin и найдите созданный локальный order. Сравните line items, amount, method, status и notes. Не ищите вымышленный LABEL-A как настоящий order number: реальные IDs назначает ваша база. Labels fixture нужны для объяснения разных сценариев и не являются импортом в WooCommerce.

Для BACS ручное изменение статуса выполняйте с пометкой, что это учебное моделирование. Нельзя объяснять читателю, будто order status Completed подтверждает перевод, которого не было. В real project подтверждение зависит от провайдера и внешнего денежного состояния. Статус магазина представляет этот результат, но ошибочная ручная правка способна сделать представление неверным.

Существуют test modes настоящих providers, однако их доступность, поддерживаемые страны, credentials и callback setup отличаются. Мы не приводим универсальный «тестовый номер карты» и не подключаем внешний аккаунт. Dummy изучает общую механику без этих зависимостей. Если следующая задача — реальная provider sandbox, для неё нужны отдельный verified guide и явно ограниченный тестовый account.

Конец урока — таблица из трёх объяснимых сценариев и понимание источника состояния. Checkout собирает намерение, gateway сообщает результат, WooCommerce сохраняет Order, а оператор читает notes. Ни один шаг не должен приписывать лаборатории движение денег. Следующая глава разберёт дальнейшие transitions: ожидание, выполнение, отмену и учебный возврат.