Qué importa primero: Stripe puede completar el pago asíncronamente, mientras que WooCommerce depende de un evento firmado para actualizar el pedido. Un webhook perdido, retrasado o rechazado deja los sistemas fuera de sincronización.
Qué indica realmente este síntoma
El ID de evento Stripe y las notas de pedido WooCommerce conectan el pago remoto a la transición del estado local.
Recopila pruebas antes de cambiar nada
- Grabar la intención de pago Stripe, ID de evento, ID de pedido y fecha y horas.
- Comprueba el estado de la entrega, el cuerpo de la respuesta y el historial de reintentación de Stripe webhook.
- Verificar endpoint URL, firma de secreto y alineación de modo vivo/de prueba.
- Inspecciona WooCommerce Stripe y logs fatal para buscar o procesar errores.
Causas más habituales
- Secreto de firma equivocado: El endpoint rechaza eventos válidos de otro modo.
- Desajuste del modo: Los eventos en vivo se envían a un punto final de la prueba o viceversa.
- Endpoint bloqueado: WAF, la autenticación básica o el mantenimiento impide la entrega.
- Procesamiento fatal: El evento llega pero el código personalizado falla al actualizar el orden.
Secuencia segura de diagnóstico y reparación
- Endpoint correcto y configuración secreta para el modo Stripe activo.
- Resolver el rechazo exacto de la entrega o el procesamiento fatal.
- Repetir un evento seguro fallido después de confirmar la idempotencia.
- Reconciliar los pagos históricos antes de actualizar manualmente los pedidos.
Cómo distinguir entre las causas probables
No trates Secreto de firma equivocado y Desajuste del modo como causas equivalentes. El endpoint rechaza eventos válidos de otro modo. En cambio, los eventos en vivo se envían a un punto final de la prueba o viceversa. Para distinguirlas, usa estas dos comprobaciones: Grabar la intención de pago Stripe, ID de evento, ID de pedido y fecha y horas; y comprueba el estado de la entrega, el cuerpo de la respuesta y el historial de reintentación de Stripe webhook. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Endpoint correcto y configuración secreta para el modo Stripe activo— o si debes conservar el estado actual y ampliar la investigación.
En una tienda activa, reproduce el problema con un pedido de prueba controlado y sigue el mismo recorrido de pago, stock, impuestos y notificaciones que usan los clientes. No cambies varios componentes del checkout a la vez, porque destruirías la evidencia necesaria para atribuir el fallo. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No marque cada pedido pendiente pagado basándose únicamente en los informes del cliente. Verifica la transacción Stripe individualmente.
Cómo verificar la reparación
- Un nuevo pago de prueba actualiza el pedido automáticamente.
- Los acontecimientos que se repiten no producen efectos secundarios duplicados.
- Stripe entrega logs y WooCommerce notas referencia al mismo evento.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.