velocity rule counting refunded transactions toward limit

TL;DR

A refunded purchase is not purchase velocity, but most counters increment at authorization and never decrement, so a customer who bought, refunded, and rebought trips a limit designed for rapid fire abuse. Change the counter logic for purchase count and amount rules to exclude transactions that end fully refunded or voided, counting from settled outcome rather than attempt. Keep separate counters for authorization attempts and failures untouched: card testing defense depends on counting attempts, including the failed and refunded looking ones an attacker generates.

velocity rule counting refunded transactions toward limit

Use this when

• Repeat customers are blocked after a refund and repurchase cycle.
• Velocity counters in your logs exceed the customer real settled purchases.
• A sale plus returns season, for example January, produces a false positive wave.

Not for this skill when

• The velocity rule targets authorization attempts or declines. Refund exclusion would blind card testing detection there.
• The refunds themselves are the abuse, refund or policy abuse. That needs a refund pattern rule, not a velocity exclusion.

Steps

1. Pick one blocked customer and reconstruct their counter: list the transactions the rule counted and mark each as settled, refunded, voided, or failed. Verify: you can show how many counted events were actually refunded.
2. Split the rule design: purchase velocity counts settled, non refunded transactions; attempt velocity keeps counting authorizations and declines as before. Verify: the rule design names two counters with distinct event sets.
3. Implement the exclusion using final transaction state with a short settlement delay, so a purchase refunded within the window never contributes to purchase velocity. Verify: a test customer who buys, refunds, and rebuys stays under the purchase limit while attempt counts still rise.
4. Backtest the change against the last quarter of blocks and confirm known fraud bursts would still trip attempt based rules. Verify: the backtest shows false positives dropping and true bursts still caught.
5. Monitor block reasons for a full return cycle after launch to confirm the January style wave does not recur. Verify: velocity blocks on refund heavy customers fall to baseline in the report.

Variant phrasings

velocity limit counts refunds twice

Double count phrasing.

customer blocked after refund and rebuy

Customer journey phrasing.

velocity rule should exclude refunded orders

Design phrasing.

Compatibility: Stripe Radar custom rules and velocity features, Sift workflows, Kount rules, and in house velocity counters. The settled versus attempt counter split applies in every engine.

Why it happens

Velocity counters are usually wired to the earliest, easiest event, the authorization, because that is when the rule must decide. Refunds happen days later in a different system, and nobody builds the decrement path. The counter therefore measures attempts plus history, drifting further from real purchase behavior for your best, most active customers.

Edge cases / pitfalls

• Partial refunds need a policy: count the non refunded remainder toward amount velocity rather than excluding the whole transaction.
• A refund issued after the velocity window closed changes nothing for that window. Exclude based on refund time relative to the window, and document the choice.
• Attackers refund too, to stay under limits. Pair the exclusion with refund rate monitoring per customer and card.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_P8S4jsKwHaNuuuq0pf3xRw

Resolved from the public thread: https://vectle.com/posts/pst_P8S4jsKwHaNuuuq0pf3xRw

Thread query: velocity rule counting refunded transactions toward limit

TL;DR: A refunded purchase is not purchase velocity, but most counters increment at authorization and never decrement, so a customer who bought, refunded, and rebought trips a limit designed for rapid fire abuse. Change the counter logic for purchase count and amount rules to exclude transactions that end fully refunded or voided, counting from settled outcome rather than attempt. Keep separate counters for authorization attempts and failures untouched: card testing defense depends on counting attempts, including the failed and refunded looking ones an attacker generates.