Una investigación necesita referencias estables y horas, no números de tarjeta. WooCommerce, la pasarela y el navegador guardan partes distintas. Unirlas permite localizar el fallo sin ampliar el acceso a datos sensibles.
Nunca pidas tarjeta completa, CVV, token de pago ni una captura que los muestre.
Define la evidencia mínima
Empieza con ID de pedido, hora aproximada y zona, importe, moneda, método y ID de transacción o payment intent. El email ayuda a localizar, pero anonímizalo en informes.
Usa una referencia única para pruebas y no reutilices la identidad de un cliente.
Pedido: 12345
Hora: 2026-07-28 14:32 Europe/Madrid
Importe: 10,00 EUR
Referencia proveedor: ID seguro
Eventos: evt_... cuando procedaConfirma que el proveedor permite compartir esos identificadores con el soporte previsto.
Define quién puede ver cada sistema antes de recopilar. El personal de soporte puede necesitar el estado y la referencia, pero no acceso completo al panel financiero. Usa permisos de solo lectura y una vía de escalado para reembolsos o cambios, en lugar de compartir una cuenta administrativa.
Empieza en el pedido
Lee las notas privadas en secuencia: creación, pasarela, ID, confirmación y cambios posteriores.
Busca la misma hora y referencia en WooCommerce > Estado > Registros. Exporta solo las líneas necesarias; un log completo puede contener otros clientes o credenciales escritas por plugins.
No actives errores públicos. Limita acceso y conservación.
Revisa si el propio plugin ya ha escrito cuerpos o cabeceras sensibles antes de activar más debug. Si detectas una API key, token o dato de pago, restringe el archivo, conserva solo la evidencia necesaria, elimina copias y rota la credencial siguiendo el procedimiento del proveedor.
Relaciona el objeto del proveedor
Busca por ID almacenado, merchant reference, número, hora e importe. Confirma si está Autorizado, Capturado, Fallido, Cancelado, Disputado o Reembolsado.
Los cuatro últimos dígitos no son una referencia única. No copies autenticación del titular ni payloads completos en notas.
Guarda el timeline y solo códigos de rechazo seguros.
Un código de rechazo puede ser suficiente para decidir la siguiente capa, pero no debe usarse para inferir o comunicar detalles financieros del cliente. Distingue errores corregibles de integración, rechazo del emisor y controles antifraude sin intentar sortear una decisión legítima.
Rastrea el webhook
Localiza eventos asociados. Anota ID, creación, intentos, estado HTTP y duración.
Un timeout no significa que WooCommerce no actuara; revisa notas y servidor antes de reenviar. Un 2xx demuestra aceptación HTTP, no que todas las tareas posteriores terminaran.
No incluyas signing secrets ni cabeceras de firma en capturas.
Cuando necesites demostrar que la firma se validó, registra un resultado booleano y el ID del evento, no la firma. Aplica la misma sustitución coherente a emails e IP para que dos apariciones se puedan correlacionar sin revelar el valor original.
Inspecciona navegador y servidor
En una reproducción controlada captura estado y respuesta del checkout. Elimina cookies, order keys, direcciones, tokens y campos antes de guardar Network.
Relaciona la hora con access logs y PHP. Un request ID del proxy es más seguro que copiar el cuerpo.
Elimina las exportaciones al terminar el periodo de retención.
Comprueba descargas locales, adjuntos de tickets, carpetas sincronizadas y copias automáticas. Borrar el log del servidor no elimina las réplicas creadas durante la investigación. El informe final debe contener la cronología y la solución, no el material bruto.
Configura logs con cuidado
Usa el modo oficial de debug solo durante el tiempo mínimo y revisa qué registra y dónde.
El logging propio debe contener identificadores, transiciones y clases de error:
wc_get_logger()->info(
'Payment callback received',
array( 'source' => 'gateway-diagnostic', 'order_id' => $order_id )
);No registres cuerpos, API keys, bearer tokens ni campos de pago. Valida que el ID exista.
Construye una cronología de traspaso
Resume qué demuestra cada sistema:
14:32 pedido creado Pendiente
14:33 proveedor captura abc…
14:33 webhook devuelve 500
14:33 fatal PHP en callback documentadoLa cronología permite una reparación enfocada y comprensible sin compartir el mensaje entero.
Incluye zonas horarias y diferencia entre creación, entrega y procesamiento.
Añade quién confirmó cada dato y desde qué fuente autoritativa. Evita frases como “el pago parece correcto”: anota “capturado según el proveedor” o “pedido Pendiente según WooCommerce”. Esta precisión evita que otro técnico convierta una inferencia en un hecho.
Cierra con responsabilidad
Concilia pedido y proveedor, corrige una vez stock o logística y registra el resultado en una nota privada. Rota cualquier credencial expuesta durante el diagnóstico.
Verifica con una transacción controlada: un pedido, un pago, un webhook y el email correcto.
El mantenimiento recurrente debe estandarizar anonimización, conservación y conciliación. La buena evidencia es breve, trazable y deliberadamente libre de datos innecesarios.