Los cobros duplicados son de esos problemas que parecen pequeños hasta que te pasan dos cosas a la vez: un cliente se enfada (con razón) y tu equipo pierde una mañana entera buscando qué ocurrió. En pymes el origen casi nunca es “un ataque”. Es una mezcla de reintentos, integraciones que se ejecutan dos veces, cambios manuales y falta de un protocolo claro de devolución.
Ya tengo en el blog un post de webhooks robustos (idempotencia y reintentos) y otro de conciliación de pagos. Este artículo no repite eso: aquí el foco es detectar cobros duplicados y actuar con un procedimiento de 60–90 minutos que puedes ejecutar aunque no seas técnico.
Paso 1 (10–15 min): define qué es “duplicado” en tu negocio. Parece obvio, pero conviene escribirlo: mismo cliente + mismo importe + misma ventana de tiempo (por ejemplo, 5–15 minutos) suele ser sospechoso. Si vendes suscripciones, el criterio cambia: duplicado puede ser dos cargos el mismo día para el mismo plan. Lo importante es que el equipo tenga la misma definición.
Paso 2 (15–20 min): saca un listado de cobros de los últimos 7–30 días. Elige una ventana razonable para empezar (yo uso 14 días si hay volumen; 30 si hay poco). Exporta desde Stripe/TPV y, si puedes, también desde tu facturación. La idea no es montar BI: es tener dos listas comparables con fecha, email/teléfono (si existe), importe y referencia.
Paso 3 (20–30 min): encuentra duplicados con dos filtros simples. Primero agrupa por email/teléfono y busca importes repetidos en una ventana corta. Luego agrupa por referencia de pedido (si la tienes). Si no tienes referencia consistente, apúntalo como causa raíz: sin identificador común, cada investigación cuesta el triple. Trade-off: este método no detecta el 100%, pero detecta rápido los casos que más dolor generan.
Paso 4 (10–15 min): clasifica la causa antes de devolver. Yo uso tres categorías: 1) error humano (se cobró dos veces manualmente), 2) reintento (el cliente no vio confirmación y pagó otra vez), 3) integración (un flujo o conexión duplicó el cobro). Esta clasificación importa porque cambia la solución: devolver sin entender causa reduce el incendio, pero no evita el siguiente.
Paso 5 (10–15 min): protocolo de actuación y tiempos. Deja por escrito: quién decide la devolución, en qué plazo (por ejemplo, 24h laborables), cómo se comunica al cliente (mensaje corto y claro), y cómo se registra el caso (una fila en una hoja con fecha, importe, causa, acción). Si lo haces bien, soporte deja de improvisar.
Errores comunes (y cómo detectarlos): 1) No registrar la referencia del pedido. Se detecta porque cada cobro “misterioso” obliga a mirar emails, WhatsApp y CRM a la vez. 2) Devolver sin anotar el motivo. Se detecta porque el mismo tipo de duplicado se repite y nadie sabe por qué. 3) Confiar solo en quejas. Se detecta porque descubres duplicados semanas después, cuando el cliente reclama o hace un chargeback (devolución forzada).
Cómo medir resultado: mide (1) número de duplicados por semana/mes, (2) tiempo medio de resolución (desde detección hasta devolución), y (3) número de tickets asociados. Si reduces el tiempo de resolución, reduces tensión y devoluciones “a lo bruto”.
Cuándo compensa delegar: si detectas que la causa es integración (por ejemplo, flujos duplicados, reintentos mal controlados o eventos repetidos), compensa que alguien revise el circuito completo de cobro. Ahí ya no es “operación”, es robustez de integración: idempotencia, referencias consistentes y trazabilidad. También delegaría si tienes varios métodos de pago (Stripe + TPV + marketplaces) y no hay un identificador común.
Nota técnica (para coordinar con un dev): pide que cada cobro tenga un id de pedido consistente que viaje por todos los sistemas (checkout, pasarela, facturación, CRM) y que cualquier automatización haga “buscar antes de crear/cobrar”. Es la forma más barata de cortar duplicados en origen.
