Velocity rules and customer limits: how to set them

Velocity rules are among the simplest fraud controls to write and among the easiest to get wrong. One line in a rules engine can stop a bot in minutes. The same line can stop your best customer on the morning of a sale, and nobody tells you, because a blocked payment leaves no complaint behind.

This article explains how velocity rules and customer limits are built, which identifiers and time windows to use, how to set thresholds without catching good repeat customers, and how to review the result. For where velocity sits among your other fraud checks, read our article on fraud screening and approval rates. For what to do during an attack, see card testing attacks.

What is a velocity rule?

A velocity rule counts events for one identifier over a time window and acts when the count passes a limit. Stripe describes velocity checks as monitoring the frequency and pattern of transactions over a window, per card, per IP address or device ID, per account, per shipping or billing address, or by total amount spent.

Every rule has four parts:

Part	Options	Example
Identifier	Card, customer account, email, device, IP address	Card
Event	Attempts, approvals, declines, blocks, amount spent	Declined attempts
Window	Minutes, hours, days, months	1 hour
Action	Allow, challenge, review, block	Require 3-D Secure

The event matters as much as the limit. Stripe’s rule attributes separate total, authorised, declined and blocked charges for each identifier, because five approvals in an hour and five declines in an hour mean different things.

A customer limit is the same idea applied to one customer and often measured in money: maximum spend per day, maximum attempts per order, maximum cards on an account. Adyen’s premium rules include an authorised amount velocity check, which triggers when a shopper’s total spend exceeds a limit within a period, with different scores at different limits.

Which identifiers should you count?

Count several, because each fails in its own way. Visa’s merchant guide advises tracking velocity on more than transactions, including email, IP address and device fingerprints. Stripe’s documentation gives a reason: an attacker can vary one signal, so rules based on a single signal, such as IP address, usually aren’t enough alone.

Identifier	Good at catching	Risk of false positives	Common use
Card	Repeat attempts on one card, card cashing	Low to medium: genuine customers retry after a typo	Attempts and approvals per hour and day
Customer account	Account takeover, abuse of promotions	Low, if accounts are real	Spend per day, cards per account
Email	Repeat fraud from one person	Low to medium: households and offices share addresses	Orders per day
Device	Many cards from one machine	Medium: identifiers can change or be shared	Different cards per device
IP address	Bots and scripts	High: many people can share one address	Attempts per minute, new accounts per day
Card shared across customers	Stolen cards used on several accounts	Medium: couples and families share cards	Adyen’s check over three months

The strongest signals are often counts of different things, such as different cards on one account. Stripe offers card counts per customer and per IP address, and Visa advises limiting the cards that can be added per account and session, and the accounts that can be created per IP address in a set time.

Why are IP limits so risky?

Because an IP address is not a person. Cloudflare’s 2025 research on carrier-grade NAT says a single IPv4 address may represent hundreds or even thousands of users, and that these shared addresses are rate limited three times more often than non-shared ones. Cloudflare says the harm falls especially on users in developing regions. For a cross-border merchant, a tight IP limit can act as a block on a mobile network in one of your growth markets. Keep IP limits high, or use them to trigger a challenge rather than a decline.

Which time windows work best?

Short windows catch attacks, and long windows catch abuse. Use more than one for the same identifier.

Window	Catches	Example rule shape
Minutes	Bots, scripted testing	Attempts per IP address per minute
1 hour	Card testing, card cashing	Declines per card per hour
1 day	Repeat fraud, stolen cards in use	Spend per customer per day
1 week to 1 month	Slow abuse, promotion abuse	Accounts per device per week
3 months or more	Cards moving between accounts	Card used by another customer

Vendor windows are not exact, so learn how yours counts. Stripe’s hourly, daily, weekly and all-time attributes use buckets, so an hourly count may reach back up to 3,900 seconds. Its counts also exclude the payment being processed, so the first attempt in an hour has a value of 0. A rule written as more than 1 will not fire on the second attempt, as you might expect, but on the third. Some of its customer counts also update only every 72 hours at most, which makes them unsuited to fast attacks.

Your own retries belong in this picture. Visa’s rules, in the October 2026 edition, allow up to 20 reattempts in 30 days for most decline codes and forbid any reattempt after a Category 1 decline, where the issuer will never approve. Stripe recommends a maximum of eight retries for charges that permit them. These are ceilings for retry jobs, not targets. Our article on merchant advice codes explains which responses to act on.

How do you set thresholds without blocking repeat customers?

Start from what genuine customers do, not from a number found online. Published figures are examples only. Stripe’s Insights tool filters at more than 10 charges per card per hour. Visa’s guide mentions five authorisations in a set timeframe. Stripe’s Radar guide shows an example block at more than 1 charge per IP address per hour. Those three figures differ widely, and that is the point. Stripe’s own advice is to base thresholds on statistical analysis of past data and to set them per risk profile or segment. Adyen says to set limits that match your shoppers’ normal behaviour.

1. Export 3 to 6 months of attempts. Stripe’s Radar guide suggests backtesting on the last six months. Include declines and blocks.
2. Remove known fraud. Take out chargebacks, fraud reports and past attacks, so the numbers show genuine behaviour.
3. Measure the distribution. For each identifier and window, count attempts per customer. Look at the top of the range, not the average.
4. Split by segment. New customers, established customers and your largest buyers behave differently. So do markets and methods.
5. Set the limit above normal. Choose a level that very few genuine customers reach, and accept that it will still catch some.
6. Add room for peaks. Stripe warns that strict rules can flag normal spikes, such as holiday or sale spending. Raise limits before a planned event, and record that you did.
7. Treat known good customers differently. Customers with a clean history can have higher limits. Stripe’s attributes include how long ago a card was first seen, which allows this kind of rule.

Example figures, for illustration only.

A fashion shop reviews six months of card attempts on 200,000 customers, excluding known fraud.

Attempts per card in 1 hour	Share of customers	What it suggests
1	91.0%	Normal
2 to 3	8.5%	Typos and retries after a decline
4 to 5	0.45%	Size changes, gift orders, some struggling customers
6 or more	0.05%	Mostly unusual; worth a look

The shop sets a challenge at 4 attempts and a block at 8. A block at 4 would have stopped 1,000 genuine customers in six months, which is 0.5% of the group. The challenge lets them finish, and the block is kept for behaviour its data suggests is rare.

Should a rule block, challenge or review?

Match the response to your certainty. Stripe’s article suggests scaling it from an alert to a decline, a one-time password or a temporary hold, because frequent false positives frustrate customers and can send them to competitors. In Visa’s guide, CAPTCHA is the tool for stopping automated activity such as five authorisations from one IP address, which keeps the door open for people.

Order also matters. In Stripe’s Radar, 3-D Secure rules run first, then allow, block and review rules, and an allow rule stops further checks. A broad allow rule can therefore switch off your velocity blocks. Whatever tool you use, learn its evaluation order before you write the rule.

How do you review the result?

A rule is finished only when you have measured what it did. Stripe’s guidance is plain: it is uncommon to find a perfect rule, so each one is a trade-off.

Before going live, run the rule against past payments. Stripe’s rule testing sorts matches into disputes and fraud warnings, refunds, blocked and failed payments, and succeeded payments. If your tool has no such test, run the rule in report-only mode. The fraud screening article covers shadow testing and how to measure false positives.

After launch, review each rule monthly:

• Volume. How many payments did it stop? A rule that fires too often is probably mis-set; one that never fires may be dead.
• Who it stopped. How many blocked customers had a good history? How many paid soon after by another route?
• Fraud caught. Of the payments it stopped, how many showed other signs of fraud? Stripe suggests feeding true and false positives back into your thresholds.
• Rate by segment. A rule that fires mostly in one country may be catching a shared mobile network, not fraud.
• Support tickets. Ask your team which messages customers see, and whether they can tell why a payment stopped.

Three vendor details can distort this review. Adyen counts abandoning a redirect or 3-D Secure step as an attempt, even though it doesn’t appear in your payments list. Its velocity rules skip recurring transactions unless you enable them. And they trigger per merchant account, not across a company, so a multi-brand group may see separate counts.

What are the common mistakes?

• Copying someone else’s limit. A shop selling phone top-ups and one selling sofas have nothing in common.
• Using IP alone. It misses rotating bots and hits shared networks.
• Counting attempts only. Declines, blocks and spend tell you different things.
• Forgetting the save-card step. Stripe says testers prefer card setup, so limit cards per account too.
• Ignoring retries and cascades. Your own retries and cascade steps can push genuine customers over a limit.
• Never loosening. A limit set during an attack should end with the attack.

How does Omno apply customer limits?

In Omno, customer rules assign providers, methods and volume thresholds by customer tag, so a new customer and a long-standing one can have different limits. You can set amount and volume limits per provider and method, block a customer fully or from specific methods, block cards, and use blacklists shared across partner merchants, with fraud scoring on every transaction. The risk controls page lists the settings.