Summary

  • Stripe's Radar frequency attributes leave out the payment being evaluated. authorized_charges_per_email_hourly is zero for an email's first charge attempt in the preceding hour; after a successful first authorization, the second attempt sees one.
  • A custom condition > 1 on that authorization counter first matches the third attempt if the first two were authorized within the hour. >= 1 would first match the second. Other rules and issuer decisions still govern the payment's actual outcome.

The extra turn of the dial

At checkout, an operator sees a run of payments from the same email and wants to stop the next one. The temptation is to treat a Radar frequency attribute like a live turnstile: payment number two arrives, so the counter says two. Stripe's guide describes a ledger with one foot behind the line. The current payment is outside the count while the rule evaluates it.

The guide's example is exact. authorized_charges_per_email_hourly counts previous successful authorizations from that email in the past hour. First attempt: zero. If it succeeds, the second attempt within the hour: one. If the second is also authorized, the third sees two. A merchant who writes > 1 has written a rule that first matches at the third attempt in that sequence. Changing one character to >= 1 moves the first possible match to the second. The clock is the preceding hour, so the same arithmetic can change as older authorizations age out.

The word before charges matters as much as the comparator. Stripe lists separate counters for authorization, attempted charges, issuer declines and blocks by Radar's machine-learning models. A failed issuer authorization does not raise the successful-authorization count in this example. A custom-rule block should not be silently counted as a machine-learning block. An operator measuring attempts while reading an authorization counter can mistake a quiet number for a quiet attack.

Stripe's current rule documentation says every transaction is screened by default Radar rules; account plans that support custom rules can add their own Allow, Block, Review or 3DS logic. The frequency count is one input to that decision. The guide also describes a rule hierarchy in which an Allow rule can take precedence over Block and Review. A zero in one frequency field therefore gives no payment a promised passage.

This is a market decision because the merchant is buying control over false positives as well as fraud. A shared IP address can accumulate legitimate customers' attempts; a rotating email can split one actor's history among several counters. The public documents specify the machinery. They provide no merchant's live rule, matching events or lost orders. The fact that would settle a particular complaint is the configured expression alongside the counter values and decisions for those payments.

Sources