Summary

  • Los atributos de frecuencia de Stripe Radar excluyen el pago evaluado. authorized_charges_per_email_hourly marca cero para el primer intento de un correo en la hora anterior; si se autoriza, el siguiente ve uno.
  • Si los dos primeros intentos se autorizan dentro de esa hora, una condición > 1 coincide por primera vez con el tercero; >= 1 podría hacerlo con el segundo. La coincidencia de esta regla no determina por sí sola el resultado del pago.

La cifra mira hacia atrás

Una tienda digital teme una ráfaga de pagos desde el mismo correo. Puede escribir una regla propia en Radar, si su plan lo permite, y escoger una frecuencia. Ahí aparece una pregunta menos vistosa que la palabra «fraude»: ¿la cifra incluye la compra que está delante de la caja? Stripe responde que no. La evaluación consulta el pasado y deja el pago actual fuera del contador.

Su ejemplo sobre authorized_charges_per_email_hourly es aritmética de caja. El primer intento de un correo en la última hora encuentra cero autorizaciones anteriores. Si el emisor lo aprueba, el segundo encuentra una. Si también se autoriza el segundo, el tercero encuentra dos. Con > 1, ese tercero es el primer candidato a coincidir. Con >= 1, lo sería el segundo. La ventana se mueve con el tiempo: un pago anterior desaparece del cálculo cuando sale de la hora precedente.

La elección del sustantivo cambia el diagnóstico. Stripe ofrece contadores de autorizaciones, intentos de cargo, rechazos del emisor y bloqueos de sus modelos de aprendizaje automático. Si una serie de tarjetas falla en el emisor, el contador de autorizaciones exitosas puede quedarse quieto. Leer ese cero como ausencia de intentos sería una torpeza cara. Del mismo modo, el contador de bloqueos del modelo no es un inventario de todas las decisiones de una regla personalizada.

La documentación vigente de Stripe dice que las reglas predeterminadas examinan todas las transacciones y que la posibilidad de crear reglas propias depende del plan Radar. La guía explica además la precedencia entre permitir, bloquear y revisar. Un pago que no coincide con este umbral todavía puede encontrarse con otra regla o con la decisión del emisor. Nadie compra un resultado completo al elegir un contador.

La tensión comercial está en la clave elegida. Una IP compartida puede reunir compradores reales; correos cambiantes pueden repartir la actividad de un atacante entre varios historiales. El operador elige dónde acepta falsas alarmas y dónde tolera otro intento. Los documentos no muestran la regla ni la conversión de un comercio concreto. Para resolver una reclamación harían falta la expresión activa, los valores que vio cada pago y su decisión final.

Sources