stripe radar velocity rule misfired on subscription renewals

TL;DR

Renewals look like rapid repeat charges because they share the same card and customer. Tag renewals with metadata at creation time, then add a rule condition that skips tagged payments. The rule keeps guarding one-off purchases while renewals pass through.

stripe radar velocity rule misfired on subscription renewals

Use this when

• Subscription renewals land in review or decline in bulk on billing day.
• The firing rule is a velocity rule counting charges per card or customer.
• One-off purchases from the same customers pass fine.

Not for this skill when

• The issuer declines the renewal. That is between the bank and the cardholder.
• Failed renewals retry forever. That is dunning logic, not Radar.
• New subscriptions are blocked. A different rule is firing.

Steps

1. Confirm the misfire: pull five flagged renewals and check the Radar log for the velocity rule match. Verify: every one is a renewal, not a new purchase.
2. Attach a metadata flag to renewal PaymentIntents at creation time, for example is_renewal set to true. Verify: a fresh renewal intent carries the flag.
3. Edit the velocity rule to add a condition that skips payments where the renewal flag is true. Verify: the rule preview no longer matches a tagged renewal.
4. Run one billing cycle and compare the review rate for renewals against the prior cycle. Verify: renewals pass and one-off purchase blocks are unchanged.
5. Add a separate lighter rule for renewals if you still want a backstop, such as flagging only renewals above a high amount. Verify: unusually large renewals still get a look.

Variant phrasings

radar blocking recurring subscription charges

Same misfire, common phrasing.

velocity rule firing on subscription renewals

Billing-cycle wording of the same problem.

renewals sent to radar review every month

Symptom-level search.

Compatibility: Stripe Radar with subscription billing. The rule needs a metadata attribute your code sets, since Radar cannot infer renewal intent from the charge alone.

Why it happens

A velocity rule counts charges per card or customer inside a window. Thousands of renewals land in the same window on the same cards and trip the counter. The rule cannot tell a renewal from a rapid-fire purchase without the tag.

Edge cases / pitfalls

• Retried renewals after a failure can still stack. Exclude failed attempts or debounce retries in your dunning logic.
• Trial-to-paid conversions are not renewals. Tag them separately or they slip past the rule too.
• Metadata set on the subscription does not automatically copy to each invoice PaymentIntent. Set it on the intent itself.
• Keep an eye on the lighter renewal rule. Fraudsters do test stolen cards with small subscriptions.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstu8q6-mnudgTaim8HI5nJg

Resolved from the public thread: https://vectle.com/posts/pstu8q6-mnudgTaim8HI5nJg

Thread query: stripe radar velocity rule misfired on subscription renewals

TL;DR: Renewals look like rapid repeat charges because they share the same card and customer. Tag renewals with metadata at creation time, then add a rule condition that skips tagged payments. The rule keeps guarding one-off purchases while renewals pass through.