WP Remote Payment Client

El problema

Una tienda necesitaba cobrar a través de una pasarela contratada por otro sitio. Había que enviar a los compradores a pagar fuera, y todo lo que ocurría después era una suposición: la tienda no tenía forma de conocer el resultado, así que un operador consultaba el otro sistema a mano y movía los pedidos. Los pedidos pagados se quedaban sin entregar; los abandonados eran idénticos a los pagados.

Las versiones ingenuas de esta integración fallan de dos formas concretas. O el endpoint de retorno queda abierto y cualquiera que descubra la URL puede marcar cualquier pedido como pagado: y la tienda se lo cree. O los dos sistemas mantienen registros de pedido separados que se desincronizan, y conciliarlos se vuelve una tarea semanal.

Antes → Después

Antes	Después
Compradores enviados fuera a pagar sin vuelta al pedido	Una pasarela de pago que devuelve un enlace y lo sigue hasta el final
El resultado del pago lo averigua una persona en otro sistema	Una llamada firmada mueve el pedido a su estado real automáticamente
Una URL de retorno que podía invocar cualquiera	Endpoints con token y cargas firmadas con HMAC
Dos sistemas, dos registros de pedido, conciliación semanal	Un pedido sombra enlazado por origen e id: búsquedas, no conciliación
Fallos invisibles hasta que un cliente se quejaba	Cada intercambio remoto escrito en una tabla con estado y carga
Conectar un sitio socio nuevo exigía tocar código	Endpoints, secreto, token y proveedor se fijan en los ajustes de la pasarela

Cómo funciona

El comprador elige la pasarela. Se registra como un método de pago normal de WooCommerce, así que aparece en el pago junto al resto de opciones y no requiere tocar la plantilla.
Se crea un pedido sombra en remoto. El pedido se serializa y se envía al sitio socio, que crea su propio pedido equivalente y devuelve un enlace de pago. Se redirige al comprador a ese enlace.
Ambos lados siguen siendo direccionables. El pedido sombra lleva el id del pedido de origen y una marca de fuente, de modo que cualquiera de los dos sistemas encuentra el registro del otro con una consulta de meta. No hay una tabla de correspondencias aparte que pueda desincronizarse.
El resultado del pago vuelve firmado. El endpoint de retorno exige token, y la carga lleva una firma HMAC verificada contra un secreto compartido con una comparación resistente a ataques de temporización. Solo entonces cambia el estado del pedido local.
Cada intercambio queda registrado. Una tabla dedicada guarda el pedido, el id del pedido remoto, la fuente, el estado, la URL de retorno y la carga en bruto: así un pago en disputa se resuelve con una consulta y no con una investigación.
Los cambios de estado se propagan. Un manejador vigila el estado del pedido local y mantiene informado al lado remoto, para que cancelar o reembolsar en un lado no deje al otro desactualizado.

Funciones clave

Pasarela de pago de WooCommerce: en el pago se ve como cualquier otro método
Creación de pedido sombra en un sitio remoto con devolución del enlace de pago
Firma de peticiones HMAC-SHA256 con verificación resistente a temporización
Endpoints REST con token: enlace, búsqueda de pedido y retorno
Correspondencia de pedidos por fuente e id de origen: sin tabla de mapeo
Tabla de registro de intercambios remotos con estado y carga
Propagación del cambio de estado del pedido hacia el lado remoto
Endpoints, secreto, token, proveedor y método de pago en los ajustes de la pasarela

Instalación

Suba la carpeta del plugin a /wp-content/plugins/ y actívelo
Ejecute la migración incluida para crear la tabla de registro de pedidos remotos
Abra WooCommerce → Ajustes → Pagos y active la pasarela de sitio externo
Rellene los tres endpoints remotos, el secreto compartido, el token de API y el nombre del proveedor
Haga un pedido de prueba y confirme que la llamada de retorno lo pasa a estado pagado