Un aviso de pago repetido no debería crear otro pedido ni ejecutar dos veces su preparación. Las integraciones necesitan distinguir la operación del negocio de las notificaciones que reciben. Antes de añadir reintentos, comprueba qué identifica cada pago, cómo se registra el trabajo realizado y qué ocurre cuando el mismo aviso vuelve a llegar.
Una etiqueta sale de la impresora. Después sale otra idéntica. El equipo busca dos pedidos, pero encuentra una sola compra. No sabes todavía si hubo dos cobros, dos avisos o una acción duplicada. Separar esos hechos es el primer paso para investigar sin culpar al comprador ni repetir una operación delicada.
Índice
- ¿Por qué un aviso puede llegar más de una vez?
- ¿Qué identifica la operación que no quieres repetir?
- ¿Cómo separar el cobro del trabajo que desencadena?
- ¿Qué pruebas detectan duplicados antes de producción?
- ¿Cómo recuperar una operación sin volver a ejecutarla?
- Cómo lo hemos abordado en meiika
- Preguntas frecuentes
¿Por qué un aviso puede llegar más de una vez?
Un webhook es una notificación que un servicio envía a otro cuando ocurre algo. Puede informar de un pago confirmado, de un cambio de suscripción o de otra modificación. La notificación y la operación no son lo mismo: recibir dos mensajes no demuestra que se hayan producido dos compras ni permite decidir automáticamente qué preparar.
Stripe advierte de que un destino puede recibir el mismo evento más de una vez y de que los eventos no tienen un orden de entrega garantizado. Su documentación recomienda identificar los eventos ya procesados y contempla duplicados con objetos de evento diferentes. Documentación de webhooks de Stripe, consultada el 12 de octubre de 2026.
Imagina un taller que vende kits de costura. Una compra confirmada genera una orden de preparación y una etiqueta. Si la integración interpreta cada aviso como una compra nueva, el equipo podría preparar dos kits. Es un ejemplo hipotético de diseño, no una incidencia observada en un cliente de meiika ni una afirmación sobre la frecuencia del problema.
El error sería exigir que nunca se repita un mensaje y dejar el resto del recorrido sin protección. Un proceso robusto debe saber qué hacer cuando recibe información que ya conoce. Esa capacidad se diseña también en una automatización visual: cambiar la herramienta no elimina la necesidad de definir la identidad y los efectos de cada operación.
¿Qué identifica la operación que no quieres repetir?
Decide primero qué significa «el mismo trabajo». Puedes querer evitar repetir la preparación de un pedido, conceder dos veces acceso a un curso o enviar de nuevo una confirmación. Esas acciones pueden depender del mismo pago, pero necesitan un registro coherente. La identidad debe corresponder al efecto que proteges, no solo a la última pantalla que abrió el usuario.
En el taller, sería útil relacionar el pedido comercial con la operación de pago y con la orden de preparación. Quien revise una incidencia debería poder localizar esa relación sin recorrer varias bandejas de correo. Una referencia estable facilita distinguir una repetición del aviso de una segunda compra legítima con productos parecidos.
La persona que construye la integración debe decidir dónde se guarda el estado y cómo evita que dos ejecuciones simultáneas hagan el mismo trabajo. Una casilla que dice «procesado» puede resultar insuficiente si ambas ejecuciones la consultan antes de que alguna la actualice. La concurrencia merece una revisión técnica, aunque el volumen habitual sea pequeño.
No uses el nombre del cliente, el importe o una fecha aislada como única prueba de identidad. Dos operaciones legítimas pueden compartir esos datos. En lugar de una deducción improvisada, pide una explicación de las referencias disponibles y del criterio de coincidencia. El equipo del negocio tiene que comprender el criterio, aunque no implemente sus detalles técnicos.
Registra también estados intermedios. Recibido, pendiente de preparación, terminado y fallido describen situaciones distintas. Un sistema que solo guarda éxito o error puede perder la pista de un trabajo parcialmente realizado. Esa diferencia determina qué se puede volver a intentar y qué exige comprobar antes su resultado.
¿Cómo separar el cobro del trabajo que desencadena?
El pago es una operación financiera; preparar un pedido es una operación logística. No debes repetir el cobro para recuperar una etiqueta que falta. Revisa qué sistema confirma el estado del pago y qué acciones posteriores se ejecutan, con sus propios registros. Esta separación hace más preciso el diagnóstico y reduce decisiones tomadas con información incompleta.
Stripe documenta el uso de claves de idempotencia para determinadas solicitudes de su API. Una clave permite reconocer un reintento de la misma petición dentro de las condiciones descritas por el proveedor. Esa función no convierte automáticamente en idempotente todo tu flujo de preparación ni sustituye la gestión de avisos entrantes. Peticiones idempotentes, consulta del 12 de octubre.
Por tanto, hay que revisar dos direcciones: lo que tu sistema solicita al proveedor y lo que hace al recibir información de él. La protección de una petición no demuestra la protección de sus consecuencias. Pide que la documentación del proyecto describa ambas, evitando una etiqueta genérica de «sin duplicados» que nadie haya comprobado.
Para el taller, una prueba podría confirmar una compra ficticia y observar la orden, la etiqueta y el aviso interno. Si falta el último paso, la recuperación debería centrarse en él, tras comprobar su estado. No se trata de añadir reenvíos ilimitados. Se trata de localizar qué efecto falta y ejecutar únicamente la recuperación que corresponda.
La información de cobros, devoluciones y obligaciones contables requiere tratamiento adecuado. Este texto es información general, no asesoramiento jurídico ni profesional. No propone ejecutar pagos o reembolsos reales durante una prueba ni fija cómo debe registrarse fiscalmente una operación concreta.
¿Qué pruebas detectan duplicados antes de producción?
Prepara escenarios con la persona responsable de la integración y utiliza el entorno de pruebas disponible. El objetivo es observar el resultado comercial, no acumular ejecuciones verdes. Una prueba se define por lo que debería quedar, por ejemplo una sola orden de preparación vinculada a una compra de prueba.
Estos escenarios ayudan a plantear la revisión:
- El mismo aviso se entrega dos veces, con la misma referencia.
- Dos avisos relacionados llegan en una secuencia diferente.
- La operación de preparación termina, pero falla su aviso interno.
- Dos ejecuciones intentan actuar sobre la misma compra.
- El equipo solicita recuperar únicamente el paso pendiente.
Cada ensayo necesita un resultado esperado y una evidencia observable. Indica qué registro debería existir, qué mensaje se recibe y qué elemento no debería repetirse. Si un escenario no puede simularse con seguridad, márcalo como no comprobado. No presentes una prueba sencilla como cobertura de todas las situaciones que puede sufrir una integración.
No uses pedidos de compradores reales como material de ensayo sin un procedimiento acordado. Puedes preparar datos ficticios y destinos internos identificados como prueba. Tampoco publiques claves, identificadores privados o información de pago en capturas compartidas. Una evidencia útil puede describir el resultado sin exponer el contenido del pedido.
¿Cómo recuperar una operación sin volver a ejecutarla?
Cuando alguien ve dos etiquetas, necesita una forma de detener la preparación y verificar las referencias. Define quién toma esa decisión y qué registros consulta. El procedimiento manual forma parte del diseño, incluso cuando la integración automatiza la mayor parte del recorrido. Una excepción no debería obligar a adivinar qué hizo el sistema.
Conserva trazas mínimas de la operación y de sus efectos. Si la preparación ya existe, volver a recibir un aviso debería conducir a una comprobación del estado, no necesariamente a repetirla. La recuperación concreta depende de tu plataforma y de cómo se construyó el flujo; no hay un botón universal que pueda recomendarse sin revisar esa configuración.
Pide un límite de reintentos y un destino para los casos que no se recuperan solos. El equipo debe poder saber cuántas operaciones siguen pendientes y por qué. Un aviso repetido durante días puede generar ruido sin resolver nada. Notificar y recuperar son responsabilidades diferentes, que conviene asignar de manera explícita.
Antes de dar la revisión por terminada, vuelve a observar el caso inicial y una repetición controlada. Documenta lo comprobado, lo pendiente y quién mantiene el circuito. No necesitas prometer que nunca habrá errores; necesitas un mecanismo verificable para distinguirlos y tratarlos sin repetir trabajo por defecto.
Cómo lo hemos abordado en meiika
En meiika presentamos sistemas a medida que conectan herramientas y decisiones de negocio. Para estudiar duplicados, el punto de partida sería dibujar las operaciones y sus referencias: dónde se confirma una compra, qué trabajo desencadena y cómo se conserva su resultado. No contamos aquí una integración implantada para un cliente.
Puedes describir el caso indicando qué aparece duplicado y qué servicio genera el aviso. No envíes claves del proveedor ni datos de tarjetas. Una revisión técnica posterior tendría que acordar accesos limitados, pruebas y alcance. Entender el efecto comercial resulta más útil que empezar añadiendo otro nodo al flujo.