Qué importa primero: Dos órdenes que parecen idénticas no son necesariamente el mismo incidente. Uno puede no tener ningún intento de pago, ambos pueden compartir un ID de transacción, o un webhook puede haber repetido una operación idempotente incorrectamente.
Qué indica realmente este síntoma
El intervalo de creación y la solicitud logs distinguen los doble clic de los reintentos del servidor y la duplicación de integración.
Recopila pruebas antes de cambiar nada
- Exportar ID de pedido duplicado, fecha y horas, cliente, hash del carrito y ID de transacción.
- Comparar las solicitudes checkout del navegador y las entregas pasarela/webhook.
- Inspecciona los ganchos personalizados conectados a checkout y la finalización del pago.
- Comprueba si el cliente volvió a juzgar después de un tiempo de espera o una página de confirmación en blanco.
Causas más habituales
- Presentación doble: El botón checkout permanece activo o JavaScript envía dos veces.
- Reintentar la red: Un proxy, cliente o integración repite una petición no idempotente.
- Duplicación de código personalizado: Un consumidor de gancho o API crea otro pedido.
- Uso indebido de Webhook: Un evento repetido ejecuta la lógica de creación de orden en lugar de actualizar el estado existente.
Secuencia segura de diagnóstico y reparación
- Haga que el checkout sumisión sea idempotente y deshabilite los clics repetidos.
- Usa claves de transacción o idempotencia únicas en integraciones pasarela.
- Corregir ganchos personalizados para actualizar el orden existente.
- Reconciliar los duplicados históricos antes de cancelar, reembolsar o restaurar stock.
Cómo distinguir entre las causas probables
No trates Presentación doble y Reintentar la red como causas equivalentes. El botón checkout permanece activo o JavaScript envía dos veces. En cambio, un proxy, cliente o integración repite una petición no idempotente. Para distinguirlas, usa estas dos comprobaciones: Exportar ID de pedido duplicado, fecha y horas, cliente, hash del carrito y ID de transacción; y comparar las solicitudes checkout del navegador y las entregas pasarela/webhook. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Haga que el checkout sumisión sea idempotente y deshabilite los clics repetidos— 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 elimine los duplicados a granel. Contienen pagos, stock, pruebas fiscales y de auditoría necesarias para decidir qué registro es autorizado.
Cómo verificar la reparación
- Una acción del cliente crea un pedido.
- La entrega repetida de webhook no crea otro orden o efecto secundario.
- Los duplicados históricos se reconcilian con las decisiones de pago y stock documentadas.
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.