Пусть выдача будет следствием оплаты, а не задачей, которую кто-то выполняет

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

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

События вместо опроса

Лечится это подвешиванием выдачи на события, которые магазин и так испускает:

add_action('woocommerce_order_status_changed', [$this, 'handle'], 10, 4);

Теперь следить не нужно ни за чем. Оплата прошла, обработчик подобрал код, код прикрепился к заказу. Три часа ночи ничем не отличаются от трёх часов дня.

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

Хранить состояние, а не зачёркивание

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

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

Одна реализация, два вызывающих

Заказы редко приходят из одного места долго. Появляется канал маркетплейса, и он ждёт выдачи за минуты.

Возникает соблазн написать под него второй путь выдачи, ведь интеграция с маркетплейсом живёт снаружи и сессии WordPress у неё нет. Соблазну лучше не поддаваться. Откройте ту же логику по закрытому токеном API:

POST /wp-json/…/activate-product-code     Authorization: Bearer <jwt>

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

Токен, кстати, а не аккаунт. Выдав интеграции админский доступ, вы дадите ей все возможности WordPress ради задачи, которой хватает одной.

Сделать внешний канал доступным для запроса

Если заказы идут с маркетплейса, система должна отвечать на вопрос «какие заказы пришли оттуда и что с ними стало» обычным запросом. Помечайте их при создании источником и исходным идентификатором.

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

Что остаётся оператору

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

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