[Blog]()Comercio # Pago repetido o aviso duplicado: cómo probar la confirmación de un pedido Dos avisos pueden ser un pago; dos pagos pueden afectar un pedido. Comprueba dinero, referencias y una sola entrega sin esconder el excedente. **[Jonathan Perez]()**Cofundador · Diseño, producto y ventas 8 de octubre de 2026 · 7 min de lectura **Respuesta breve** Para probar la confirmación de un pedido, distingue la referencia del aviso, la del pago y la del pedido. Un aviso repetido conserva la aplicación anterior; un segundo cobro real se registra y revisa aunque tenga el mismo importe. Confirma importe, moneda y cuenta antes de preparar, y comprueba que reintentar no genere otra entrega ni oculte dinero recibido. ## Pruebas de avisos duplicados y doble cobro Diez casos sintéticos que distinguen aviso, pago y pedido, con excedente, reembolso pendiente y validación de moneda. [Descargar hoja CSV]() En esta guía - [Distingue el aviso del movimiento de dinero]() - [Ejemplo: un pedido de 750 y avisos repetidos]() - [Una pantalla de éxito no debe decidir sola la entrega]() - [Define la confirmación completa del pedido]() - [Prueba repetición y doble cobro por separado]() ## Distingue el aviso del movimiento de dinero Un aviso de pago, también llamado webhook, es un mensaje del proveedor hacia la tienda. Su llegada no es un cobro nuevo. Para decidir qué ocurrió, conserva tres referencias distintas: pedido, pago del proveedor y aviso recibido. Dos mensajes pueden describir el mismo pago; dos pagos confirmados pueden pertenecer por error al mismo pedido. Cada situación necesita una respuesta diferente. [Stripe advierte]() que un aviso puede recibirse varias veces, que pueden existir eventos diferentes del mismo objeto y tipo, y que la entrega no está garantizada en el orden de generación. Su documentación recomienda distinguir referencias ya procesadas. Son condiciones de Stripe, no prueba de cómo funciona tu tienda. Pide comprobar que un aviso repetido mantiene un solo pedido y que un segundo cobro real queda visible. | Situación |Evidencia |Respuesta esperada en la prueba | | --- | --- | --- | | Mismo aviso otra vez |Misma referencia de aviso y pago |Conservar el resultado anterior | | Otro aviso del mismo pago |Aviso distinto; mismo pago y hecho |No aplicar dinero ni preparar mercancía otra vez | | Segundo pago real |Referencia de pago distinta y cobro confirmado |Registrar ambos; revisar excedente antes de otra entrega | ## Ejemplo: un pedido de 750 y avisos repetidos **Escenario sintético de aceptación** Pedido OP-62 por 750 MXN, sin impuestos ni cargos adicionales. Política propuesta: un pedido comercial conserva una entrega; cobros adicionales inesperados van a revisión con responsable. Los identificadores son ficticios y no describen un proyecto de Nightly ni una cuenta real. | Paso |Hecho |Resultado comprobable | | --- | --- | --- | | 1 |PAGO-A se confirma por 750; llega AV-1 |OP-62 pagado; una asignación 750; una preparación | | 2 |AV-1 llega otra vez |Misma asignación; no generar otra orden | | 3 |AV-2 describe el mismo PAGO-A confirmado |Conservar 750 aplicados; no otra salida | | 4 |PAGO-B también se confirma por 750 |Dos cobros reales = 1500; excedente 750 por revisar | | 5 |Otro aviso de PAGO-B llega |Seguir con dos cobros, no tres; una revisión del excedente | Ignorar el paso 4 como «duplicado» ocultaría 750 cobrados de más. Crear otro pedido y otra entrega también sería incorrecto si el comprador solo aceptó OP-62. Conserva ambos movimientos, su relación con el pedido y la decisión de la persona autorizada. Si el comprador sí hizo dos compras distintas, cada una necesita su aceptación y referencia propias; el mismo importe no determina la intención. Si se autoriza devolver PAGO-B, registra la solicitud de reembolso y espera evidencia de su resultado. [Stripe documenta]() que ciertos reembolsos pueden quedar pendientes y otros fallar según método y condiciones; no llama a una solicitud «dinero devuelto». Mientras esa devolución siga pendiente, el registro de PAGO-B permanece y el excedente conserva su seguimiento. ## Una pantalla de éxito no debe decidir sola la entrega El comprador puede cerrar la ventana después de pagar o quedarse sin conexión antes de ver el resultado. La tienda debe consultar la evidencia autorizada del proveedor y relacionarla con OP-62. «No volvió a la página» no significa «no pagó»; «vio una pantalla de éxito» tampoco sustituye la verificación de importe, moneda y cuenta receptora. Muestra pago por revisar cuando esa información siga incierta. Prueba un aviso de pago fallido que llegó tarde después de otro resultado ya confirmado. Antes de cambiar un pedido pagado a fallido, revisa qué intento describe y cuál es su estado autorizado actual. Conserva el historial en lugar de tratar el último mensaje recibido como la última realidad. La [conciliación de pagos]() sirve para reconstruir lo ocurrido cuando los avisos no bastan. ## Define la confirmación completa del pedido - Relacionar pedido, intento de compra y pago: evita que un pago de otra compra confirme OP-62. - Validar proveedor, cuenta, moneda, importe y resultado: un mensaje ajeno o una diferencia no confirma automáticamente el pedido. - Conservar cada aviso y su efecto: permite distinguir recepción de aviso y actualización del pedido. - Separar confirmar pago, preparar y entregar: cada acción se demuestra una vez, aunque lleguen varias notificaciones. - Asignar excedentes y resultados inciertos a una persona: define próxima acción y plazo de revisión. ## Prueba repetición y doble cobro por separado 1. Normal: un pago correcto confirma una asignación y permite una preparación. 2. Aviso repetido: enviar el mismo aviso varias veces conserva el pedido y las cantidades. 3. Avisos distintos: dos mensajes del mismo pago no aplican 750 dos veces. 4. Cobro adicional: otro pago realmente exitoso se registra y revisa; no se pierde ni duplica mercancía. 5. Respuesta perdida: repetir la consulta o confirmación recupera OP-62; no obliga al comprador a pagar nuevamente por falta de respuesta. 6. Excepción: importe 749, moneda diferente o aviso no verificable permanece por revisar sin entrega confirmada. La hoja descargable contiene diez pruebas sintéticas con la evidencia esperada y espacio para resultados. La guía de [avisos y reintentos entre sistemas]() desarrolla el proceso general; aquí el foco es conservar el dinero y la intención de una compra. Revisa también [cancelación y reembolso]() para seguir una devolución pendiente. Al evaluar [software para comercios](), lleva un pedido anonimizado y las referencias de los mensajes y pagos que lo afectaron. Identifica quién puede consultar el proveedor y quién autoriza devolver un excedente. Sin esos accesos y decisiones, una conexión nueva puede recibir más avisos sin resolver la duda de qué debe entregar tu equipo. ## Sigamos las referencias de un pago dudoso En un diagnóstico gratuito podemos revisar si tu proceso duplicó un aviso, recibió otro cobro o perdió la confirmación. - Un pedido anonimizado y las referencias de los pagos asociados. - Los avisos y estados del proveedor con hora, importe y moneda. - Quién consulta pagos y quién autoriza resolver excedentes o reembolsos. [Agendar diagnóstico gratuito]()[Consultar por WhatsApp]() Relacionado - [Software para comercios]() - [Páginas web y tiendas en línea]() ## Preguntas frecuentes ### ¿Dos avisos significan dos cobros? No. Pueden describir el mismo pago. Comprueba las referencias de pago y aviso, no solo el número de mensajes. ### ¿Debo ignorar un segundo cobro del mismo importe? Si tiene otra referencia y se confirma como dinero realmente recibido, regístralo y revisa el excedente. Ignorarlo puede ocultar una obligación de resolverlo. ### ¿La pantalla de éxito basta para entregar? Comprueba el resultado autorizado, importe, moneda y pedido. Si falta evidencia, muestra revisión y un responsable. ### ¿Reembolso solicitado significa dinero devuelto? No. Conserva su referencia y estado hasta verificar el resultado. Un pago adicional sigue registrado mientras la devolución permanece pendiente. ## Fuentes 1. [Recibir y manejar eventos de Stripe]()Stripe 2. [Reembolsar y cancelar pagos]()Stripe Última actualización: 8 de octubre de 2026 ## Sigue leyendo [Comercio8 oct 2026 ### Conciliar pagos con pedidos: referencias, diferencias y revisión]()[Eventos de integración8 oct 2026 ### Webhooks que fallan: reintentos sin duplicar trabajo ni perder eventos]()[Comercio8 oct 2026 ### Cancelar un pedido: surtido, pago y reembolso confirmado]() --- Canonical: https://nightlysoftware.com/blog/pagos-repetidos-webhooks Updated: 2026-10-08 Description: Distingue otro aviso de un segundo cobro real. Prueba confirmación, entrega única y excedentes con un ejemplo y diez casos descargables.