Проблема с неоплаченными или неподтверждёнными заказами в WooCommerce
В WooCommerce часто возникает ситуация, когда покупатели создают заказы, но не завершают оплату или платеж остаётся в состоянии ожидания слишком долго. Такие «зависшие» заказы занимают ресурсы базы данных, и при использовании платёжных систем с авторизацией и последующим подтверждением может потребоваться автоматический возврат средств, если заказ не подтвердился в течение определённого времени.
По умолчанию WooCommerce не выполняет автоматический возврат денег для неподтверждённых заказов, что приводит к необходимости ручного контроля и обработки.
Диагностика проблемы: как понять, что возврат не происходит автоматически
- Проверьте в админке WooCommerce раздел "Заказы" — если много заказов со статусом
on-holdилиpendingстарше нескольких дней, это индикатор проблемы. - Сравните платежи в платёжной системе и статусы заказов — если деньги списаны, но статус заказа не обновился, возврат не выполнен.
- Просмотрите логи WooCommerce и платёжного шлюза на наличие ошибок при попытках обновления статуса.
Пошаговое решение: автоматизируем возврат средств для неподтверждённых заказов
1. Определяем критерии возврата
Рекомендуется выбрать заказы со статусом on-hold или pending, которые не изменялись более заданного времени, например 3 дня.
2. Создаём функцию для автоматического возврата через API платёжного шлюза
В WooCommerce возврат средств осуществляется функцией $order->refund(), но для автоматизации нужно использовать API платёжного шлюза (например, Stripe, PayPal). Ниже пример на Stripe.
function wc_auto_refund_unconfirmed_orders() {
$args = array(
'status' => array('pending', 'on-hold'),
'date_created' => '<' . ( time() - 3 * DAY_IN_SECONDS ),
'limit' => -1
);
$orders = wc_get_orders($args);
foreach ($orders as $order) {
if (!$order->get_transaction_id()) {
continue; // Нет ID транзакции, возврат невозможен
}
// Подключаем Stripe SDK и инициализируем (пример)
$stripe = new \Stripe\StripeClient('sk_test_your_secret_key');
try {
$refund = $stripe->refunds->create([
'charge' => $order->get_transaction_id(),
]);
if ($refund->status === 'succeeded') {
$order->update_status('refunded', 'Автоматический возврат по неподтверждённому заказу');
$order->add_order_note('Возврат средств выполнен автоматически.');
}
} catch (Exception $e) {
error_log('Ошибка возврата для заказа ' . $order->get_id() . ': ' . $e->getMessage());
}
}
}
add_action('woocommerce_scheduled_auto_refund', 'wc_auto_refund_unconfirmed_orders');3. Создаём cron-задачу для регулярного запуска
Регистрируем событие и запускаем его, например, раз в сутки.
function wc_schedule_auto_refund() {
if (!wp_next_scheduled('woocommerce_scheduled_auto_refund')) {
wp_schedule_event(time(), 'daily', 'woocommerce_scheduled_auto_refund');
}
}
add_action('wp', 'wc_schedule_auto_refund');Проверка результата после внедрения решения
- Через несколько дней в разделе «Заказы» не должно быть неподтверждённых заказов старше 3 дней со списанными, но не возвращёнными средствами.
- В админке заказа появится статус
refundedи соответствующие заметки. - В логах ошибок отсутствуют записи о неудачных возвратах.
- Сравните отчёты платёжной системы и WooCommerce — возвраты должны совпадать.
Частые ошибки и как их исправить
- Отсутствие ID транзакции
Проверяйте, что при оплате сохраняется корректныйtransaction_id. Без него возврат невозможен. - Неинициализированный SDK платёжного шлюза
Убедитесь, что SDK правильно подключён, и ключи актуальны. - Отсутствие cron-задачи
Проверьте через WP-CLIwp cron event list, что событиеwoocommerce_scheduled_auto_refundзапланировано. - Права доступа
Плагин или тема должны иметь доступ к интернету для работы с API платёжного шлюза.
Практические советы по безопасности и производительности
- Храните API-ключи платёжного шлюза в
wp-config.phpили с помощью плагинов для безопасного хранения секретов. - Обрабатывайте возвраты пакетно, чтобы не перегружать сайт при большом количестве заказов.
- Реализуйте логирование успешных и неудачных попыток возврата — это поможет быстро диагностировать проблемы.
- Ограничьте права пользователя, под которым запускается скрипт, чтобы снизить риски безопасности.
Сравнение вариантов решения автоматического возврата
| Подход | Преимущества | Недостатки |
|---|---|---|
| Ручной возврат через админку | Простота, контроль | Трудозатратно, риск пропуска |
| Автоматизация через кастомный код и API | Экономия времени, регулярность | Сложность настройки, зависит от API |
| Плагины возврата (платные/бесплатные) | Готовое решение, поддержка | Стоимость, возможные конфликты |