Состояния заказа и подтверждение оплаты
Состояние заказа описывает его текущий этап, а история notes помогает понять, почему этап изменился. Оплаченный, отменённый и возвращённый order не являются разными цветами одной карточки: у них разный смысл для исполнения и аналитики. В «Полке» проследим известные цифровые items через ожидание, учебное подтверждение, отказ и manual refund.
Результат урока — понятная таблица transitions и проверка конкретного Order в панели. Fixtures содержат вымышленные labels, а не импортируемые records. Проект не запускался; состояния ниже ожидаемые. Ни один manual transition лаборатории не подтверждает реальную оплату или возврат денег.
Draft и полученный заказ
Block checkout может создавать временный Draft order до окончательной отправки. Это техническое состояние оформления, а не оплаченная продажа. В актуальном интерфейсе drafts имеют собственное представление в Orders. Если вы увидели новую record после открытия Checkout, не прибавляйте её сразу к количеству покупателей.
Pending payment означает, что order получен, но оплата ещё не выполнена. On hold означает ожидание подтверждения, например выбран BACS. Эти состояния похожи отсутствием окончательного успеха, но у них разные причины и дальнейшие действия. Notes и payment method позволяют объяснить разницу на конкретном объекте.
Официальные определения находятся в Order Statuses. В нашей лаборатории BACS заказ на GRID-PDF должен быть On hold после оформления. Не переводите его в Processing, только чтобы сделать список зеленее: сначала решите, какой учебный результат вы моделируете и запишите это в note.
Если покупатель прервал оформление, данные cart и Order могут сохраняться какое-то время по правилам продукта. Это не универсальная потеря покупки и не обязательная продажа. Для аналитики следует определить, какой этап считается завершённым, а для очистки — какой набор технических records можно удалить без утраты нужной истории.
Успех и исполнение связаны с типом товара
Processing обычно сообщает, что payment получен, а order ещё требует исполнения. Completed означает завершение. Когда все items одновременно virtual и downloadable, WooCommerce может завершить order автоматически после корректного payment completion. Это соответствует нашему цифровому assortment, но не обязательно относится к любому товару с надписью «онлайн».
Представим физическую книгу с downloadable памяткой. Она downloadable, но не virtual; shipping всё ещё нужен. После success заказ может ожидать исполнения в Processing. Изменить его в Completed только ради открытия файла — плохое смешение двух задач. Настройка Grant access after payment позволяет рассмотреть downloads отдельно от физической доставки.
Для «Полки» откройте учебный Dummy success order и сравните flags line items с итоговым status. Если one Product только virtual без downloadable, автоматическое поведение может отличаться. Проверьте исходные данные товара, а не добавляйте глобальный фильтр «всегда Completed» для скрытия несогласованности.
Переходы также запускают notifications и integrations. Если operator меняет status несколько раз, система может сформировать несколько писем или webhook events. Guard перехватывает mail, но история всё равно остаётся. Поэтому в course examples сохраняем notes и отдельные scenario IDs, а не перебрасываем один order между всеми состояниями без смысла.
Ошибка, отмена и возврат
Failed сообщает о неуспешной оплате. Cancelled — об отмене заказа. Отмена не равна возврату уже полученных денег: если payment был успешен, потребуется отдельное действие provider/refund. В нашей лаборатории денег нет, но важно не выучить неверную связь между двумя состояниями.
Refunded появляется при полном возврате стоимости в модели Order. WooCommerce допускает manual refund, который отражает сумму внутри магазина без автоматической отправки денег через gateway. Для учебного проекта именно такой сценарий подходит, однако описание должно сохранять это различие. Нельзя сообщить «деньги возвращены», если выполнена лишь правка учёта.
Частичный refund не всегда переводит весь order в Refunded, потому что часть line items остаётся исполненной. Следовательно, reports должны читать actual refunds и totals, а не только status label. Отдельная цифровая покупка за 20 может иметь возврат 8; Net sales тогда отличаются от исходной суммы, хотя title заказанного конспекта не изменился.
Файл fixtures/orders.json содержит небольшую синтетическую модель для дальнейшего сравнения.
{
"synthetic": true,
"not_importable": true,
"orders": [
{
"label": "LAB-A",
"items": [
"GRID-PDF"
],
"status": "on-hold",
"amount": "12.00",
"meaning": "Ожидает учебного подтверждения"
},
{
"label": "LAB-B",
"items": [
"GRID-PDF",
"FORM-ZIP"
],
"status": "completed",
"amount": "18.00",
"coupon": "LAB10",
"meaning": "Dummy success; все товары virtual+downloadable"
},
{
"label": "LAB-C",
"items": [
"HTML-EXT"
],
"status": "failed",
"amount": "24.00",
"meaning": "Dummy failure"
},
{
"label": "LAB-D",
"items": [
"URL-TXT"
],
"status": "refunded",
"amount": "5.00",
"meaning": "Учебный manual refund; банковского движения нет"
}
]
}LAB-B использует LAB10 из будущего двенадцатого урока. Это заранее заданное ожидаемое состояние всего course, не уже выполненный заказ. Labels полезны для обсуждения разных сценариев; при вашей работе рядом следует записать actual Order ID. Файл явно помечен not_importable, поскольку штатный product importer не создаёт Orders из такого JSON.
Order сохраняет собственные значения
Цена line item записана в заказе. Если regular price GRID-PDF изменится в каталоге завтра, старый заказ не обязан пересчитаться. То же относится к скидке и именам выбранных options. Анализировать продажу по сегодняшней Product price можно лишь с отдельной ясной целью, например оценкой нового предложения, а не как фактическую сумму старой покупки.
У заказа есть notes, billing contact и права загрузки. Не публикуйте screenshot со всеми этими values, если когда-либо работаете с реальными данными. В лаборатории используем вымышленные contacts и не создаём изображения запусков. Для редакционного объяснения достаточно таблицы transitions и описания поведения.
При custom code обращайтесь к Order через WooCommerce CRUD, например wc_get_order, а не напрямую к wp_posts. HPOS меняет способ хранения и требует поддерживаемого интерфейса. Сам статус виден в UI и API; внутреннее размещение records не должно стать скрытой зависимостью вашего учебного plugin.
Для самостоятельного опыта создайте отдельный BACS order, добавьте private note «Учебное подтверждение без денег» и измените его состояние согласно сценарию. Затем сравните с отдельным Dummy failure order. Состав и суммы должны оставаться объяснимыми, а причины transitions — читаться из истории. Все эти действия выполняет читатель локально; они не происходили при подготовке серии.
Завершённый результат — вы различаете технический draft, ожидание payment, исполнение, отмену и учётный возврат. Далее посмотрим, как эти состояния влияют на доступ к файлу: Completed без правильно настроенных downloadable resources ещё не делает цифровой магазин готовым.