tophercris

Actualización: causa raíz encontrada tras investigación más profunda

Después de depurar con más detalle, encontré una explicación más precisa de lo que está ocurriendo.

Lo que sí llega al pedido:

Los pedidos afectados SÍ tienen el meta _Mercado_Pago_Payment_IDs escrito correctamente (ej: 161143988100). Al consultar la API de MP directamente (GET /v1/payments/161143988100) con el token de producción, la respuesta es status: approved / status_detail: accredited. El pago existe y es accesible.

Dónde se rompe el flujo:

La notificación IPN llega → el plugin comienza a procesarla → escribe algunos metadatos en el pedido (incluyendo _Mercado_Pago_Payment_IDs) → luego intenta una consulta al KVS → el KVS responde 404 CPP_NT_0602004 → el plugin aborta antes de llamar a update_status().

El punto clave: el payment ID se escribe en el pedido antes de la llamada al KVS, pero la actualización del estado ocurre después. El fallo del KVS interrumpe el flujo exactamente en el paso que cambiaría el pedido a procesando.

Esto confirma el fix que necesita el plugin:

Cuando se lanza CPP_NT_0602004, el plugin debería hacer fallback a consultar GET /v1/payments/{id} directamente usando el payment ID ya guardado en los metadatos del pedido, en lugar de abortar. Los datos están disponibles vía la API de pagos — el KVS es solo una capa de caché/lookup que está fallando intermitentemente del lado de MP.

Workaround temporal (automatizado):

Como el payment ID siempre está presente en los metadatos del pedido, es posible implementar un WP-Cron que consulte la API de pagos de MP directamente para los pedidos atascados en pending o cancelled y los actualice automáticamente. Esto bypasea el flujo IPN roto hasta que MP corrija el problema del KVS en sus servidores.

• This reply was modified 2 weeks, 1 day ago by tophercris.