Un cobro sin pedido visible es una incidencia urgente. Debes saber si existe fuera de la lista normal, si el checkout falló tras crear el pago o si código propio inició el cobro antes de guardar de forma duradera.
No pidas comprar otra vez. Conserva el informe, revisa la pasarela y evita un segundo cargo.
Verifica qué significa “cobrado”
Solicita hora aproximada, importe, moneda y email, nunca números de tarjeta. Distingue en el proveedor una autorización o retención bancaria de un pago capturado.
Registra ID de transacción y merchant reference. Busca por email, importe y fecha en todos los estados, incluida la papelera, considerando zonas horarias.
El concepto bancario por sí solo puede no identificar la tienda.
Comunica al cliente que la transacción se está conciliando y pídele que no repita la compra hasta recibir una respuesta. No solicites capturas que muestren tarjeta completa, saldo u otras operaciones. Un justificante redactado y la referencia del proveedor suelen ser suficientes.
Busca pedidos ocultos o draft
Los checkouts modernos pueden crear pedidos Draft antes del pago. HPOS también revela código antiguo que busca únicamente posts.
Usa la API de pedidos:
$orders = wc_get_orders( array(
'billing_email' => 'controlled-test@example.com',
'limit' => 20,
) );No introduzcas datos reales en herramientas públicas ni compartas la salida completa.
Revisa también estados personalizados y migración HPOS.
Sigue la referencia del proveedor
Los metadatos del pago pueden incluir ID de pedido, order key, carrito o URL del sitio. Inspecciona el objeto y su historial de eventos.
Si apunta a un pedido que WooCommerce no carga, revisa errores MySQL, migración de almacenamiento y borrados. No crees otro con el mismo número modificando IDs.
Si no existe referencia, documenta el hueco: la integración puede iniciar el pago demasiado pronto.
Comprueba que el objeto de pago pertenece al dominio, cuenta de comercio y entorno correctos. Una clave cruzada entre staging y producción puede crear cobros en una cuenta mientras la tienda busca el pedido en otra configuración.
Inspecciona checkout y PHP
Relaciona las horas de creación y captura con servidor web, PHP, WooCommerce y pasarela. Un fatal tras autorizar puede impedir la respuesta o el guardado final.
Busca errores de escritura, deadlocks, memoria agotada y excepciones. No muestres debug públicamente.
Un timeout del navegador no demuestra que el servidor no actuara. Revisa estados antes de reproducir.
Revisa el webhook
El webhook puede actualizar un pedido existente, pero normalmente no debería inventar uno completo desde un payload no confiable. Comprueba entregas 403, 404, 500 o timeout.
Reenvía solo tras verificar sitio, evento e idempotencia. El evento equivocado puede duplicar preparación o emails.
Conserva firmas y cuerpos únicamente en logs protegidos.
Decide reconstruir o reembolsar
Confirma si el producto puede entregarse y si existen datos fiscales, envío y consentimiento necesarios. Un pedido manual solo es apropiado si se documenta su relación con el pago verificado.
Usa administración o API soportada, guarda la referencia y notas privadas. No inventes impuestos ni direcciones.
Si no es posible cumplir, reembolsa mediante el proceso del proveedor y registra el resultado. No marques reembolsado sin evidencia.
Cuando se reconstruya, marca claramente el origen manual y evita volver a capturar el pago. Verifica stock, numeración fiscal, emails y acceso del cliente; el pedido recuperado debe enlazar con la transacción existente, no iniciar otra.
Repara la secuencia
Corrige persistencia MySQL, compatibilidad HPOS, personalización, recursos o integración. El inicio del pago debe vincularse a una referencia duradera y los callbacks repetidos no pueden duplicar efectos.
Prueba en sandbox forzando fallos alrededor de autorización, retorno y webhook.
Revisa que el sistema conserve una trazabilidad segura incluso cuando el navegador se cierre.
Verifica y monitoriza
Completa una transacción controlada y sigue petición, pedido, pago, webhook, stock, email y logística. Confirma un registro por etapa.
Concilia todos los pagos del intervalo de la incidencia contra WooCommerce antes de cerrarla.
El mantenimiento recurrente debe comparar transacciones y pedidos y alertar sobre referencias sin correspondencia. La mejor respuesta es detectarlo antes de que el cliente tenga que demostrar que pagó.