WP Remote Payment Client

Проблема

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

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

До → После

До	После
Покупатель уходит платить на сторону без пути обратно в заказ	Шлюз в оформлении заказа возвращает ссылку на оплату и ведёт её до конца
Результат оплаты узнаёт человек, заглянув в другую систему	Подписанный колбэк сам переводит заказ в реальный статус
Адрес колбэка, который мог дёрнуть кто угодно	Эндпоинты за токеном и полезная нагрузка с HMAC-подписью
Две системы, две записи заказа, еженедельная сверка	Теневой заказ связан источником и исходным id: не сверка, а поиск
Сбои не видны, пока не пожалуется клиент	Каждый обмен пишется в таблицу лога со статусом и телом запроса
Подключить новый сайт-партнёр - значит править код	Эндпоинты, секрет, токен и провайдер задаются в настройках шлюза

Как это работает

Покупатель выбирает шлюз. Он регистрируется как обычный способ оплаты WooCommerce, поэтому появляется при оформлении рядом с остальными вариантами и не требует правок темы.
Теневой заказ создаётся на той стороне. Заказ сериализуется и уходит на сайт-партнёр, тот создаёт свой соответствующий заказ и возвращает ссылку на оплату. Покупателя перенаправляют на неё.
Обе стороны остаются адресуемыми. Теневой заказ несёт id исходного заказа и метку источника, поэтому любая из систем находит запись другой обычным мета-запросом. Отдельной таблицы соответствий, которой свойственно разъезжаться, просто нет.
Результат оплаты возвращается подписанным. Эндпоинт колбэка требует токен, а тело запроса несёт HMAC-подпись, которая проверяется по общему секрету сравнением, устойчивым к атаке по времени. Только после этого меняется статус локального заказа.
Каждый обмен логируется. Отдельная таблица пишет заказ, id удалённого заказа, источник, статус, адрес колбэка и сырое тело запроса - поэтому спорный платёж разбирается запросом, а не расследованием.
Смены статуса распространяются. Обработчик следит за статусом локального заказа и держит удалённую сторону в курсе, чтобы отмена или возврат с одной стороны не оставляли другую с устаревшими данными.

Основные возможности

Платёжный шлюз WooCommerce - в оформлении заказа выглядит как любой другой способ
Создание теневого заказа на удалённом сайте с возвратом ссылки на оплату
Подпись запросов HMAC-SHA256 с проверкой, устойчивой к атаке по времени
REST-эндпоинты за токеном: ссылка, поиск заказа, колбэк
Сопоставление заказов по источнику и исходному id - без таблицы соответствий
Таблица лога удалённых обменов со статусом и телом запроса
Передача смены статуса заказа обратно на удалённую сторону
Эндпоинты, секрет, токен, провайдер и способ оплаты - всё в настройках шлюза

Установка

Загрузите папку плагина в /wp-content/plugins/ и активируйте
Прогоните встроенную миграцию, создающую таблицу лога удалённых заказов
Откройте WooCommerce → Настройки → Платежи и включите шлюз внешнего сайта
Заполните три удалённых эндпоинта, общий секрет, токен API и имя провайдера
Проведите тестовый заказ и убедитесь, что колбэк переводит его в оплаченный статус