WooCommerce Purchase Order Gateway - Плагин WordPress

Руководство по настройке WooCommerce Purchase Order Gateway для B2B-заказов

WooCommerce Purchase Order Gateway нужен не для онлайн-эквайринга, а для другого сценария: покупатель оформляет заказ в магазине, выбирает оплату по номеру закупочного заказа и оставляет этот номер в оформлении заказа. В этом руководстве разберём, как подготовить магазин, где включить метод оплаты, какие тексты показать покупателю, как обрабатывать заказ в админ-панели и как не перепутать такой сценарий с обычной банковской оплатой.

Материал рассчитан на владельцев WooCommerce-магазинов, менеджеров B2B-продаж и вебмастеров, которым нужно принимать корпоративные заказы без немедленного платежа на сайте. Мы не будем повторять короткое описание продукта. Вместо этого пройдём рабочую цепочку: настройка платежного метода, проверка поля на checkout, обработка статуса On hold, сверка номера закупочного заказа, письма, подписки с ручными продлениями и диагностика типичных ошибок.

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

Какой сценарий закрывает покупка по номеру закупочного заказа

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

WooCommerce Purchase Order Gateway добавляет именно такой управляемый вариант оплаты. В checkout появляется платежный метод, покупатель выбирает его и вводит номер закупочного заказа, который был выдан или согласован вне сайта. После отправки заказа WooCommerce не считает оплату подтверждённой автоматически. Заказ остаётся в статусе ожидания проверки, а менеджер должен сверить данные и только потом двигать заказ дальше по процессу.

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

Когда такой метод оплаты действительно уместен

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

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

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

Когда лучше выбрать другой подход

Если вам нужен обычный банковский перевод с реквизитами, часто достаточно встроенного метода Direct Bank Transfer. Если оплата происходит при вручении товара, ближе будет Cash on Delivery. Если нужно ограничивать способы оплаты по роли, сумме заказа, стране или составу корзины, отдельный плагин с условиями показа платёжных методов даст больше контроля. WooCommerce Purchase Order Gateway стоит выбирать тогда, когда центральная сущность процесса - именно номер закупочного заказа, а не банковские реквизиты, курьерская оплата или сложная логика ограничений.

Что проверить перед установкой в магазине WooCommerce

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

Начните с версии WordPress, WooCommerce и PHP. На странице продукта WooCommerce Marketplace указаны текущие требования и результаты проверки совместимости, но такие данные быстро обновляются, поэтому перед установкой ориентируйтесь на карточку продукта и документацию WooCommerce.com, а не на старые обзоры. Если магазин давно не обновлялся, сначала проверьте совместимость темы, платёжных методов и расширений оформления заказа на staging-копии.

Операционная подготовка

Плагин будет полезен только если внутри бизнеса есть понятная процедура. До установки ответьте на несколько вопросов:

• Кто выдаёт или подтверждает номер закупочного заказа: менеджер продаж, бухгалтерия, отдел закупок клиента или внешняя система?
• Что должен сделать менеджер WooCommerce после получения заказа: сверить клиента, проверить лимит, запросить документ, выставить счёт, передать на склад?
• Какой статус означает, что заказ ещё нельзя выполнять, и кто переводит его дальше?
• Какие письма получает клиент, чтобы не подумать, что заказ уже оплачен и отправлен?
• Нужно ли показывать этот метод всем клиентам или только заранее согласованным B2B-покупателям?

Последний вопрос особенно важен. Базовый плагин даёт сам метод оплаты и поле номера, но не является полноценной системой B2B-доступа. Если метод должен появляться только для определённых ролей, групп клиентов или заказов выше заданной суммы, планируйте дополнительное ограничение через подходящий WooCommerce-инструмент, а не обещайте это только настройками Purchase Order Gateway.

Техническая подготовка checkout

Проверьте страницу оформления заказа. У WooCommerce есть классический checkout и блочный checkout, и разные расширения по-разному работают с этими режимами. Официальная документация Purchase Order Gateway описывает путь настройки через WooCommerce > Settings > Payments и показывает метод оплаты как часть checkout. Если ваш магазин сильно изменяет checkout через тему, конструктор, поля, кеш или отдельные B2B-расширения, обязательно протестируйте вывод метода на копии сайта.

Практическая проверка: перед включением на живом магазине создайте тестовый товар, пройдите checkout от имени обычного клиента и от имени B2B-клиента, затем убедитесь, что номер закупочного заказа виден в карточке заказа и не теряется в письмах.

Установка и первое включение без лишнего риска

Установка выполняется как у обычного WooCommerce-расширения. После получения ZIP-файла в своём аккаунте WooCommerce администратор загружает его через Plugins > Add New, выбирает Upload Plugin, устанавливает и активирует расширение. После активации сам метод оплаты нужно найти в настройках WooCommerce, потому что платежные шлюзы обычно управляются не из общего списка плагинов, а из раздела оплат.

Официальный путь настройки: WooCommerce > Settings > Payments, затем метод Purchase Order. В старых материалах иногда встречается название вкладки Checkout, но в актуальном интерфейсе WooCommerce используется раздел оплат. Если у вас локализованная админ-панель, названия могут быть переведены, но логика та же: настройки WooCommerce, раздел способов оплаты, управление конкретным методом.

Первое включение

1. Откройте WooCommerce > Settings > Payments.
2. Найдите метод Purchase Order и перейдите в его настройки.
3. Включите параметр Enable/Disable, если хотите показать метод в checkout.
4. Задайте понятный Title, который увидит покупатель.
5. Заполните Description, чтобы объяснить, кто может использовать этот метод и какой номер нужно ввести.
6. При необходимости добавьте Thank you note, чтобы на странице благодарности не возникало ощущения мгновенной оплаты.
7. Сохраните изменения через Save Changes.

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

Минимальная проверка после активации

После сохранения откройте checkout в приватном окне браузера. Добавьте тестовый товар в корзину, заполните адрес, выберите Purchase Order и проверьте, что поле номера появляется в нужном месте. Затем отправьте заказ и откройте его в WooCommerce > Orders. В карточке заказа должны быть видны выбранный метод оплаты и введённый номер закупочного заказа.

Тексты в checkout: как объяснить покупателю правила PO-оплаты

Самая недооценённая часть настройки - не переключатель включения, а текст, который покупатель видит в checkout. Для обычной оплаты картой пользователь понимает, что будет списание. Для purchase order это не так очевидно. Нужно коротко объяснить, что номер должен быть заранее согласован, что заказ будет проверен вручную и что выполнение начнётся после подтверждения магазина.

В настройках Purchase Order Gateway есть поля Title, Description и Thank you note. Они влияют на разные моменты пользовательского пути. Title помогает выбрать правильный метод оплаты. Description объясняет условие использования прямо до отправки заказа. Thank you note снижает риск неверного ожидания после оформления.

Как выбрать название метода

Название должно быть понятным вашим клиентам. Если покупатели привыкли к термину "номер закупочного заказа", можно написать: "Оплата по номеру закупочного заказа". Если аудитория работает с английскими PO-номерами, допустим вариант "Purchase Order / PO number", но в русскоязычном магазине лучше не оставлять непонятную аббревиатуру без пояснения.

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

Что написать в описании

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

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

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

Что написать на странице благодарности

Thank you note полезен для снижения ошибок в коммуникации. После отправки заказа клиент должен понимать, что заказ принят, но не обязательно уже оплачен или готов к отгрузке. Формулировка может быть такой: "Мы получили заказ с номером закупочного заказа. Менеджер проверит данные и свяжется с вами, если потребуется уточнение".

Не обещайте автоматическую отправку, если по процессу менеджер сначала проверяет номер и наличие товара. Для Purchase Order Gateway честная формулировка важнее рекламной: она защищает магазин от споров и помогает клиенту понять следующий шаг.

Статус заказа, письма и ручная проверка менеджером

После выбора Purchase Order заказ попадает в ручной сценарий. Документация плагина указывает, что заказ помещается в статус On hold до тех пор, пока владелец магазина вручную не отметит его как выполненный. Это поведение логично для offline-методов: WooCommerce получил заказ, но не получил автоматического подтверждения платежа от внешнего процессинга.

Важно понимать смысл статуса On hold. В WooCommerce он обычно означает, что заказ ожидает подтверждения оплаты или ручной проверки. Для закупочного заказа это не ошибка, а нормальная остановка процесса. Менеджер должен открыть заказ, найти номер закупочного заказа, сверить клиента и решить, что делать дальше.

Что видит менеджер в заказе

В карточке заказа нужно проверить не только номер PO, но и весь контекст заказа. Сначала убедитесь, что выбран именно метод Purchase Order. Затем проверьте имя клиента, компанию, адрес, состав заказа, доставку, налоговые данные и примечания. Если номер закупочного заказа должен соответствовать договору или внутреннему лимиту, сверка выполняется вне WooCommerce - в CRM, ERP, бухгалтерской системе или таблице продаж.

После проверки у менеджера обычно есть три варианта:

• Подтвердить заказ и перевести его дальше по принятому процессу, если номер корректен и товар можно выполнять.
• Оставить заказ в On hold, если нужно запросить подтверждение, документ или исправление номера.
• Отменить заказ, если клиент выбрал метод без права на PO-оплату или указал недействительные данные.

Как не потерять контроль над выполнением

Главная ошибка - воспринимать заказ с Purchase Order как уже оплаченный. Для товаров, которые требуют отгрузки, резервирования или ручной сборки, настройте внутреннее правило: заказ не передаётся на склад, пока ответственный сотрудник не проверил номер закупочного заказа. Если складская интеграция забирает заказы только в определённых статусах, убедитесь, что On hold не запускает отгрузку раньше времени.

В некоторых магазинах полезно добавить отдельный внутренний статус через WooCommerce Order Status Manager, например "PO проверяется" или "Ожидает счёт". Это уже не функция Purchase Order Gateway, но близкий сценарий: базовый плагин принимает номер, а отдельный инструмент помогает описать многоступенчатый B2B-процесс. Такой подход стоит использовать только если команде реально не хватает стандартных статусов WooCommerce.

Практический пример: корпоративный заказ расходных материалов

Разберём предметный сценарий. Допустим, магазин продаёт расходные материалы компаниям. Постоянный клиент согласовал покупку с отделом закупок и получил внутренний номер заказа. Ему нужно оформить заказ в WooCommerce, чтобы менеджер увидел товары, адрес доставки и номер PO в одной карточке.

Цель

Нужно настроить метод оплаты так, чтобы корпоративный клиент мог выбрать покупку по номеру закупочного заказа, ввести номер, получить понятное сообщение после оформления, а менеджер увидел заказ в On hold и проверил его перед выполнением.

Подготовка

• В магазине установлен WooCommerce и активирован WooCommerce Purchase Order Gateway.
• Есть тестовый товар с обычной ценой и включённой доставкой, если доставка важна для вашего процесса.
• Создан тестовый клиент или можно оформить заказ как гость, если это разрешено правилами магазина.
• Менеджер знает тестовый PO-номер, например PO-TEST-1001, и понимает, что это не реальный заказ.

Шаги настройки и проверки

1. Откройте WooCommerce > Settings > Payments > Purchase Order.
2. Включите метод и задайте название "Оплата по номеру закупочного заказа".
3. В описании напишите, что метод доступен только для корпоративных клиентов с согласованным номером.
4. В Thank you note добавьте сообщение о ручной проверке менеджером.
5. Сохраните настройки и откройте магазин в приватном окне.
6. Добавьте тестовый товар в корзину, перейдите к оформлению, выберите метод Purchase Order и введите PO-TEST-1001.
7. Отправьте заказ, затем откройте его в админ-панели WooCommerce.

Ожидаемый результат

Покупатель должен увидеть понятное сообщение после оформления. В админ-панели заказ должен быть создан с методом оплаты Purchase Order, номером закупочного заказа и статусом ожидания ручной проверки. Менеджер должен видеть, что этот заказ нельзя автоматически считать оплаченным.

Нюанс, который часто мешает тесту

Если метод не появился в checkout, сначала проверьте, включён ли он в Payments и сохранены ли настройки. Затем посмотрите, не скрывает ли checkout другой плагин, правило по ролям, кэш страницы или кастомная тема. Если checkout сильно кастомизирован, временно проверьте метод на стандартной странице оформления заказа, чтобы отделить проблему плагина от проблемы шаблона.

Проверка результата после настройки

Проверка должна включать не один успешный checkout, а всю цепочку. Purchase Order Gateway влияет на оформление заказа, карточку заказа, письма и дальнейшую обработку. Если проверить только наличие поля в checkout, можно пропустить проблему в письме, статусе или внутреннем регламенте.

Чек-лист для тестового заказа

• Метод оплаты виден там, где должен быть виден, и не появляется в неподходящем сценарии, если вы ограничиваете доступ дополнительными средствами.
• Текст метода ясно говорит, что номер закупочного заказа должен быть заранее согласован.
• Покупатель не получает сообщение, которое можно прочитать как "заказ уже оплачен".
• В карточке заказа виден номер закупочного заказа и метод оплаты.
• Статус заказа соответствует ручной проверке, а не автоматическому выполнению.
• Письма не вводят клиента и менеджера в заблуждение.
• Складская, CRM или бухгалтерская интеграция не запускает выполнение до проверки.

Как проверить письма

Письма особенно важны, потому что именно они формируют ожидание у клиента. Сделайте тестовый заказ на адрес, к которому у вас есть доступ, и проверьте письмо клиента. Затем проверьте уведомление администратора или менеджера магазина. Если в письмах нет нужного контекста, скорректируйте тексты метода и внутренние инструкции. Официальный changelog плагина также показывает, что размещение номера PO на странице благодарности и в письмах является значимой частью продукта, поэтому этот пункт нельзя пропускать.

Как проверить аналитику и конверсию

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

Как встроить PO-оплату в B2B-процесс магазина

Успешная настройка WooCommerce Purchase Order Gateway заканчивается не на поле checkout. Если магазин работает с корпоративными покупателями, каждому заказу нужна понятная дорога после нажатия кнопки оформления. Иначе плагин будет технически работать, но команда начнёт спорить, что означает заказ в On hold, когда его можно собирать, кто должен связываться с клиентом и какие документы нужно подготовить.

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

Разделите публичные и внутренние сообщения

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

Не пытайтесь уместить весь внутренний регламент в Description на checkout. Покупателю достаточно понять условие выбора метода. Менеджеру нужен отдельный чек-лист в CRM, в базе знаний или в инструкции по обработке заказов WooCommerce. Такой раздел может включать список признаков корректного PO-заказа, контакты ответственных сотрудников и правила изменения статуса.

Определите момент, когда заказ можно выполнять

Для разных магазинов этот момент отличается. Одному магазину достаточно сверить номер и клиента, другому нужно получить PDF от отдела закупок, третьему - согласовать лимит с бухгалтерией. Важно не название статуса, а однозначное правило. Например: "Склад видит заказ только после перевода из On hold в Processing" или "Заказ остаётся в ожидании, пока менеджер не добавит внутреннюю заметку с результатом проверки".

Если у вас есть интеграция со складом, проверьте, какие статусы она забирает. Некоторые коннекторы отправляют в складскую систему все новые заказы, другие - только Processing или Completed. Для purchase order это критично: преждевременная отгрузка до проверки номера может создать финансовый риск. В тестовом сценарии специально оформите заказ с PO-методом и убедитесь, что он не уходит в выполнение раньше нужного момента.

Используйте order notes как журнал проверки

В карточке заказа WooCommerce есть заметки заказа. Для PO-сценария они удобны как лёгкий журнал: кто проверил номер, что ответил клиент, почему заказ оставлен в ожидании, когда можно двигать дальше. Это не заменяет полноценную CRM, но помогает команде не терять контекст внутри WooCommerce.

Хорошая внутренняя заметка короткая и проверяемая: "PO-TEST-1001 сверён с договором, лимит подтверждён, можно передавать на сборку" или "Номер не найден, отправлен запрос клиенту". Не пишите в заметках конфиденциальные данные, которые не должны храниться в заказе. Если у вас есть правила обработки персональных или финансовых данных, согласуйте их с юристом или ответственным за безопасность.

Ограничения, о которых стоит знать заранее

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

Проверка номера остаётся за магазином

Если покупатель вводит номер, WooCommerce получает строку. Дальше магазин сам решает, что с ней делать. У одного клиента номер может выглядеть как PO-1001, у другого - как длинная комбинация из отдела, даты и проекта. Без интеграции с внешней системой плагин не знает, правильный это номер или нет. Поэтому в тексте checkout важно не писать "номер будет проверен автоматически", если такой проверки нет.

Ограничение доступа не является основной функцией

Многие B2B-магазины хотят показывать purchase order только оптовым клиентам. Это разумное требование, но его нужно подтверждать конкретным инструментом. Если у вас уже есть роли клиентов, ценовые группы или закрытый B2B-каталог, проверьте, может ли ваша система условий скрывать или показывать payment gateway. Если нет, покупатель без права на PO-оплату может увидеть метод и отправить заказ с произвольным номером.

Самый безопасный путь - запустить базовую настройку на тестовой копии, затем добавить правила ограничения и проверить несколько ролей: гость, обычный покупатель, B2B-клиент, менеджер. Для каждого пользователя нужно понимать, виден ли метод, можно ли оформить заказ и что появляется в карточке заказа.

Документы и счета зависят от вашей системы

Официальная документация указывает, что номер purchase order отображается в order information и invoice. Но конкретный внешний вид счёта, шаблон PDF, поля письма и экспорт в бухгалтерию зависят от используемых расширений и темы писем. Если магазин использует отдельный плагин PDF invoices, ERP-коннектор или кастомные шаблоны писем, проверьте, попадает ли PO-номер туда, где его ждёт бухгалтерия клиента.

Не считайте тест завершённым, пока не увидели финальный документ или письмо в том виде, в котором его получает клиент. Иногда поле есть в заказе, но не выводится в нужном PDF-шаблоне. Это уже вопрос интеграции с шаблоном документа, а не базовой настройки Purchase Order Gateway.

Лучшие настройки для аккуратного запуска

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

Ниже - практическая таблица, которая помогает выбрать формулировки и не перегружать покупателя. Это не официальные значения, а редакционная схема для русскоязычного магазина. Адаптируйте её под договоры, отрасль и внутренний тон коммуникации.

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

Подписки, ручные продления и B2B-ограничения

Официальная документация Purchase Order Gateway отдельно упоминает совместимость с WooCommerce Subscriptions при одном важном условии: поле purchase order появляется при покупке подписочного товара, если в настройках Subscriptions включены ручные продления. Если ручные продления не включены, поле не появляется. Это логично: PO-оплата не является автоматическим списанием, поэтому она ближе к ручному процессу продления.

Для магазинов с подписками это не техническая мелочь, а бизнес-решение. Если клиент оформляет подписку по номеру закупочного заказа, кто будет подтверждать каждое продление? Будет ли клиент получать новый номер PO для каждого периода? Нужно ли создавать pending order и отправлять счёт вручную? Эти вопросы лучше решить до включения метода на живом сайте.

Как мыслить ручное продление

WooCommerce Subscriptions поддерживает ручные платежи: в таком сценарии создаётся заказ на продление, который должен быть оплачен или обработан через доступный платежный метод. Если вы разрешаете Purchase Order для подписок, настройте процесс так, чтобы менеджер видел не только первый заказ, но и последующие продления. Иначе можно получить активную подписку, по которой заказ ожидает ручной проверки, а команда не понимает, нужно ли предоставлять доступ, отгружать товар или ждать новый номер.

Когда не стоит включать PO для подписок

Если ваш продукт требует автоматического продления без участия клиента, Purchase Order не будет удобным основным методом. Он не заменяет токенизированную карту или платёжный шлюз с автоматическими recurring-платежами. Для подписок с корпоративными договорами он может быть полезен, но только при чётком регламенте: кто выдаёт номер, как создаются renewal orders, когда подписка остаётся активной и когда её нужно приостановить.

Безопасные улучшения без правки кода плагина

Для Purchase Order Gateway обычно лучше начинать не с PHP-snippet, а с текстов, статусов, ролей и тестов. У официальной документации нет подтверждённого публичного набора hooks именно для изменения логики этого плагина, поэтому не стоит выдумывать фильтры или менять файлы расширения. Любая доработка должна быть обратимой и не ломать checkout.

Если нужно визуально выделить метод оплаты в checkout, можно использовать небольшой CSS в дочерней теме или через безопасный инструмент для пользовательского CSS. Такой подход не меняет обработку заказа и легко откатывается. Перед применением проверьте HTML вашего checkout, потому что классы и структура могут отличаться в зависимости от темы и режима оформления заказа.

Небольшое визуальное выделение метода

Задача этого примера - добавить спокойный акцент к строке метода оплаты, чтобы корпоративный клиент заметил описание. Вставляйте код только в место, где вы обычно храните пользовательский CSS: дочерняя тема, раздел дополнительных стилей темы или проверенный CSS-плагин. Не редактируйте файлы WooCommerce и Purchase Order Gateway.

/* Аккуратный акцент для метода Purchase Order в checkout.
   Перед публикацией проверьте фактический ID метода в HTML вашего сайта. */
.woocommerce-checkout #payment .payment_method_purchase_order {
  border: 1px solid #d6e4ff;
  background: #f7fbff;
  padding: 12px;
  border-radius: 6px;
}

После добавления откройте checkout, выберите Purchase Order и проверьте, что блок не перекрывает поля, не ломает мобильную версию и не делает остальные методы оплаты менее понятными. Если тема использует другой идентификатор метода или блочный checkout выводит иную разметку, удалите CSS и подберите селектор по фактическому HTML. Откат простой: удалить этот фрагмент и очистить кеш страницы, если он включён.

Что лучше решать отдельными расширениями

Если вам нужно показывать Purchase Order только определённым ролям, странам, суммам заказа или товарам, не пытайтесь решать это CSS. Нужна серверная логика ограничения платежных методов. В WooCommerce Marketplace есть инструменты вроде Conditional Shipping and Payments, которые работают именно с условиями для платежей и доставки. Если же вам нужны дополнительные поля, например отдел, имя закупщика или внутренний код проекта, ближе будет класс расширений для checkout fields, но здесь важно учитывать совместимость с вашим режимом checkout.

Почему Purchase Order может не работать как ожидается

Большинство проблем с этим плагином связано не с самим полем PO-номера, а с ожиданиями вокруг статусов, писем и checkout. Ниже - практическая диагностика: симптом, вероятная причина, проверка и безопасное исправление.

Метод оплаты не отображается в checkout

Симптом

Администратор включил Purchase Order, но покупатель не видит этот способ оплаты на странице оформления заказа.

Что проверить

• Метод включён в WooCommerce > Settings > Payments и изменения сохранены.
• На странице checkout выбран товар, для которого вообще доступна оплата.
• Другие плагины не скрывают платёжные методы по роли, стране, доставке, сумме или составу корзины.
• Кеш страницы не отдаёт старую версию checkout.
• Тема или конструктор не заменяет стандартный checkout несовместимой разметкой.

Начните с отключения правил ограничения платежей на staging-копии. Если метод появляется, проблема не в Purchase Order Gateway, а в условиях показа. Если не появляется, проверьте активность плагина, ошибки JavaScript на checkout и совместимость с текущим checkout-режимом.

Заказ остаётся в On hold и команда считает это ошибкой

Для PO-заказа статус On hold обычно является ожидаемым поведением. Заказ не должен автоматически становиться Completed, потому что WooCommerce не получил подтверждённый онлайн-платёж. Исправление здесь организационное: обучите менеджеров проверять такие заказы, добавьте внутренний чек-лист и не передавайте их на выполнение до сверки.

Диагностический ориентир: если в заказе выбран Purchase Order и есть PO-номер, сначала проверяйте бизнес-процесс. Если тот же статус появляется у карт или других шлюзов, тогда смотрите документацию конкретного платёжного метода и order notes.

Покупатели вводят случайные номера

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

Номер есть в заказе, но менеджер не видит его в своём процессе

Проверьте, где именно менеджер работает с заказом. Если он открывает карточку заказа в WooCommerce, номер должен быть виден в order information. Если менеджер работает в ERP, CRM, складской системе или выгрузке, нужно проверить, передаёт ли интеграция метаданные заказа. Не обещайте автоматическую передачу в стороннюю систему, пока не проверили конкретный коннектор.

Письмо клиенту выглядит как подтверждение оплаты

Скорректируйте тексты метода и страницу благодарности. Для Purchase Order важна формулировка "заказ получен и ожидает проверки", а не "оплата успешно получена". Если письма сильно кастомизированы, проверьте шаблоны писем WooCommerce и расширения для счетов. Не меняйте ядро плагина: сначала используйте настройки текста и штатные инструменты кастомизации писем.

Подписочный товар не показывает поле PO

Проверьте настройки WooCommerce Subscriptions. Документация Purchase Order Gateway указывает, что поле появляется для подписочного товара при включённых ручных продлениях. Если ручные продления отключены, покупателю не будет предложен этот сценарий. Исправление - включать manual renewals только если бизнес действительно готов обрабатывать продления вручную.

Когда WooCommerce Purchase Order Gateway будет удачным выбором

WooCommerce Purchase Order Gateway хорошо подходит магазинам, где B2B-заказ должен пройти через сайт, но оплата и подтверждение идут по корпоративному процессу. Он добавляет в checkout понятный метод, сохраняет номер закупочного заказа и помогает менеджеру обрабатывать такие заказы внутри WooCommerce. Особенно полезен продукт для постоянных клиентов, закупок по договору и сценариев, где номер PO должен попасть в заказ и документы.

Не стоит ждать от него функций, которых он не обещает: автоматической проверки номера в ERP, выдачи PO-номера клиенту, сложных условий показа или полноценного управления статусами. Эти задачи решаются регламентом, интеграциями или дополнительными WooCommerce-расширениями. Хорошая настройка начинается с текста в checkout и заканчивается понятным внутренним процессом: кто проверяет номер, когда заказ можно выполнять и что получает клиент в письмах.

Если ваш магазин уже работает с корпоративными покупателями и вам нужен аккуратный способ принимать заказы по согласованному PO-номеру, можно скачать последнюю версию WooCommerce Purchase Order Gateway, установить плагин на тестовой копии и пройти полный сценарий от checkout до ручного подтверждения заказа. После успешного теста перенесите настройки на рабочий сайт и подготовьте короткую инструкцию для менеджеров.