Que la entrega sea consecuencia del pago, no una tarea que alguien ejecuta

La entrega digital manual tiene una forma que se reconoce desde lejos. Alguien vigila la lista de pedidos, busca un código libre en una hoja de cálculo, lo pega en un correo y lo tacha.

Todas las propiedades de ese sistema se derivan de la persona que está en medio. La entrega tarda lo que esa persona tarde en darse cuenta. Se detiene cuando duerme. Y el mismo código no sale dos veces únicamente porque presta atención, lo cual no es una garantía: es una esperanza con buen historial.

Eventos, no sondeo

El arreglo consiste en colgar la entrega de los eventos que la tienda ya emite:

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

Ahora no hay que vigilar nada. Entra el pago, el manejador resuelve un código y el código se adjunta al pedido. Las tres de la madrugada funcionan igual que las tres de la tarde.

Los eventos son preferibles a un cron que rastrea pedidos sin completar por dos motivos: latencia y honestidad. Un rastreador tiene un periodo, y ese periodo es un retraso que decides imponer a cada cliente. Un manejador de eventos se ejecuta cuando ocurre la cosa. Conserva el rastreador como red de seguridad para pedidos cuyo evento se perdió, pero que no sea la vía principal.

Guardar estado, no un tachón

Los códigos deben vivir en una tabla con estado por código, y el motivo no es el orden. Emitir un código y activarlo son hechos distintos. Un código entregado a un cliente que nunca lo canjeó no es lo mismo que uno consumido, y un negocio que no los distingue no puede responder si el cliente recibió realmente aquello por lo que pagó.

Una celda tachada en una hoja de cálculo colapsa ambos hechos en un solo bit. Y lo colapsa de forma destructiva: el estado anterior desaparece.

Una implementación, dos llamantes

Los pedidos rara vez llegan de un solo sitio durante mucho tiempo. Aparece un canal de marketplace y espera la entrega en minutos.

La tentación es escribir una segunda vía de entrega para él, porque la integración vive fuera y no tiene sesión de WordPress. Conviene resistirse. Expón la misma lógica a través de una API autenticada:

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

La lógica de entrega queda entonces con exactamente una implementación y dos llamantes. La alternativa de dos implementaciones significa que cualquier cambio futuro en cómo funciona la entrega hay que hacerlo dos veces. Y el día en que alguien lo haga una sola vez, los dos canales empiezan a comportarse distinto. Ese fallo enloquece, porque por separado las dos vías parecen correctas.

Un token, dicho sea de paso, y no una cuenta: darle a una integración una cuenta de administrador le concede todas las capacidades de WordPress para resolver un problema que necesita una.

Haz consultable el canal externo

Si los pedidos vienen de un marketplace, el sistema debe responder con una consulta a la pregunta de qué pedidos llegaron de allí y qué pasó con ellos. Márcalos al crearlos con su origen y su identificador de procedencia.

Sin eso, conciliar los dos sistemas se convierte en una tarea manual periódica, es decir, el trabajo que quitaste de la entrega reaparece en contabilidad. El patrón se repite: todo aquello por lo que vayas a preguntar después, regístralo en el momento en que ocurre. Reconstruirlo más tarde a partir de marcas de tiempo e importes es adivinar con una hoja de cálculo puesta.

Qué le queda al operador

Automatizar la entrega no elimina personas. Cambia lo que hacen: en vez de ejecutar cada entrega, atienden las que fallaron. Es mejor uso de una persona y un trabajo mucho más pequeño, pero solo funciona si los fallos son visibles. Una tubería automatizada que falla en silencio es peor que un proceso manual, porque nadie vigila lo que antes se vigilaba por definición.

Así que el mismo commit que automatiza la entrega debería hacer ruidoso el fallo: una nota en el pedido, un estado que destaque en la lista, una línea de log con el identificador del pedido dentro.