Cómo diseñar un programa de referidos que no se pueda hackear
Todo incentivo monetario automatizado es, en el fondo, un sistema de seguridad. Las reglas que separan un programa de referidos sano de uno que se autodestruye.
Un programa de referidos parece, a primera vista, una feature simple: un usuario comparte un código, otro lo usa, ambos reciben un crédito. La complejidad real aparece cuando se reconoce lo que realmente es: un sistema que regala dinero automáticamente basado en una condición que el propio usuario controla. Cualquier sistema con esa forma va a ser atacado, no porque los usuarios sean deshonestos por naturaleza, sino porque un incentivo monetario mal protegido es, literalmente, una invitación.
El vector de ataque más obvio, y por qué no es el único
El fraude más evidente es el auto-referido: crear una segunda cuenta para "referirte a ti mismo" y cobrar el crédito de ambos lados. Bloquear esto solo con un unique: true en el código de referido no alcanza, porque el atacante no reutiliza el mismo dato, cambia el correo, cambia el número de teléfono, a veces incluso cambia la dirección de envío. La pregunta de diseño no es "¿cómo evito que se use el mismo dato dos veces?", es "¿qué señales, combinadas, hacen que dos cuentas probablemente sean la misma persona?"
Algunas señales que sí generalizan bien:
- Dirección de envío o facturación compartida entre el referidor y el nuevo usuario.
- Mismo dispositivo o huella de red en la creación de ambas cuentas.
- Patrón temporal sospechoso: cuentas creadas en un intervalo de segundos entre sí, repetidamente.
Ninguna señal por sí sola es concluyente, un domicilio compartido puede ser legítimo (una pareja, una familia). El diseño correcto no bloquea con una sola señal, acumula evidencia y decide con un umbral, igual que un sistema de detección de fraude en pagos.
El segundo vector: abuso de volumen, no de identidad
Incluso con identidad verificada, un programa de referidos sin límites es vulnerable a abuso de volumen: alguien que genera decenas de referidos legítimos en un patrón que, aunque técnicamente válido, no es el comportamiento que el programa pretendía incentivar. Aquí las defensas son distintas: topes de crédito acumulable, ventanas de expiración que fuerzan a que el beneficio se use pronto en vez de acumularse indefinidamente, y límites por periodo que hacen que escalar el abuso deje de ser rentable.
La regla de diseño que se repite
Lo que une ambos vectores es una idea simple: un incentivo automático nunca debería depender de una sola condición fácil de simular. "Nuevo comprador" no es una condición robusta si "nuevo" se define solo por un correo distinto. "Un uso por pedido" no es robusto si no se ata también a la identidad real de quien compra. Cada regla de negocio ingenua ("solo compradores nuevos pueden usar el código") necesita traducirse en dos o tres señales técnicas independientes, porque un atacante solo necesita encontrar la más débil.
Por qué esto se generaliza más allá de e-commerce
Cualquier sistema que reparte valor automáticamente basado en una acción del usuario, créditos de referido, cashback, recompensas por completar una acción, hereda este mismo problema. La ingeniería de seguridad aquí no es exótica: es aplicar el mismo pensamiento defensivo que se usaría en autenticación o en pagos, a un lugar donde intuitivamente parece "solo una feature de marketing". Tratar un incentivo monetario como una feature de producto, sin el rigor de seguridad que merece, es la forma más común en que estos programas terminan costando más de lo que generan.