Velocity checks in payment fraud prevention are automated filters that count how many times a specific data point — a card number, an IP address, an email, a failed authorization — appears within a set time window, and then block or flag the transaction when that count crosses a preset threshold. They exist mainly to stop card testing attacks, where fraudsters run stolen card numbers through a checkout page in bulk to find which ones still work. The hard part is calibration: thresholds tight enough to catch bots but loose enough to let real customers through.
The Attack Velocity Checks Are Built to Stop
Card testing, sometimes called enumeration or carding, is almost always automated. A script can push hundreds or thousands of card numbers per minute against a single checkout page, cycling through combinations of card numbers, expiration dates, and CVVs until it finds a valid set. The transactions are typically small, often under $10, because low-value attempts are less likely to draw scrutiny.1Visa. Anti-Enumeration and Account Testing Best Practices
The merchant pays a processing fee on every attempt, whether it succeeds or not. Without velocity rules catching the pattern early, a targeted merchant can rack up significant fees and get flagged by their card network within hours.
What Velocity Checks Track
A velocity check counts occurrences of specific identifiers across transactions, then compares those counts against limits. The identifiers are the ways the system links separate attempts back to the same card, person, or device.
The most fundamental one is the card number itself, known in the industry as the Primary Account Number. If the same card number appears in 20 authorization attempts over five minutes, that pattern shows up no matter what name, email, or address is attached to each attempt. Processors also track the IP address of the device initiating the purchase, which catches a single computer cycling through different card numbers.2U.S. Payments Forum. Velocity Checks
Beyond those, systems catalog email addresses, phone numbers, and billing and shipping addresses submitted during checkout. That lets the system group transactions that share identifiers even when the card number changes. More advanced setups add device fingerprinting, which combines browser settings, operating system details, screen resolution, and hardware configuration to identify a specific machine. A fraudster might swap cards and emails between attempts, but the fingerprint often holds steady.
Newer platforms layer in behavioral signals: typing speed, mouse movement, and how the user interacts with the checkout form. Automated scripts produce distinctly robotic input — perfectly consistent keystroke timing, no mouse drift, instant form completion. A real shopper pauses, scrolls back, fixes typos. These markers help separate a human from a bot even when the traditional identifiers look clean.
How Thresholds and Time Windows Work
Every velocity rule has three parts: a data element to count, a maximum number of occurrences, and a time window in which to count them.2U.S. Payments Forum. Velocity Checks A simple rule: no more than three authorization attempts from the same card number in 60 minutes. A more targeted one: no more than five failed transactions from the same IP address in 10 minutes. Merchants stack multiple rules across different data elements and time windows to build a layered net.
Short windows of one, five, or ten minutes catch the rapid-fire attacks where a bot hammers the checkout at machine speed. Longer windows of 24 hours or a week catch slower attempts where a fraudster deliberately spaces out transactions to stay under the short-window radar. Most merchants run both at once.
Rolling Windows vs. Fixed Windows
How the window itself is calculated matters more than most merchants realize. A fixed window resets at set intervals, say every hour on the hour. The problem is obvious. A fraudster who submits four transactions at 12:58 and four more at 1:02 has made eight attempts in four minutes without ever exceeding a “five per hour” limit in either window. Rolling windows solve this by continuously recalculating. At any moment, the system looks back over the preceding 60 minutes and counts everything in that span. No reset boundary to exploit. The tradeoff is computational cost, since rolling windows require the system to maintain and query a running tally for every tracked identifier, but the accuracy gain is worth it for fraud work.
Tuning Thresholds by Product Type
Not every product deserves the same limits. Digital goods like gift cards, software licenses, and game currency are high-risk because they can be resold instantly and don’t need a shipping address that might trigger further verification. Merchants selling these products often set tighter limits: fewer attempts per card, shorter windows, lower tolerance for failed authorizations. Physical goods with longer fulfillment cycles can afford somewhat looser thresholds. The U.S. Payments Forum recommends building thresholds around customer-segment behavior rather than applying one set of rules to all traffic, since one-size-fits-all rules tend to be either too restrictive for real shoppers or too lenient for fraud.2U.S. Payments Forum. Velocity Checks
Real-Time Evaluation
The evaluation happens in milliseconds, between the moment a customer clicks “pay” and the moment the authorization request reaches the payment processor. The gateway receives the transaction data, queries its internal database for prior records matching the card number, IP, email, or device fingerprint, and tallies previous attempts within each active window. If every count falls below its threshold, the transaction passes the velocity check and moves to the next verification stage.
If any count meets or exceeds a threshold, the system executes whatever response the merchant has configured: an immediate decline, a manual review flag, or a step-up authentication challenge. The check runs on every transaction and updates its counts in real time, so the next incoming attempt sees the new tally.
Sophisticated systems don’t just count total attempts. They also track the ratio of failures to successes. A card number with 15 consecutive declines followed by one approval is a textbook brute-force pattern: the fraudster likely found a working combination of card number, expiration date, and CVV after testing many invalid ones. The velocity engine can flag this even if the raw count hasn’t hit its limit, because the failure-to-success sequence matches known attack behavior.1Visa. Anti-Enumeration and Account Testing Best Practices
What Happens When a Limit Trips
The most common response is a hard decline. The transaction is blocked before it ever reaches the issuing bank, and the customer sees a generic error message. Some processors return a specific response code; PayPal’s Payflow system returns result code 125, which indicates the transaction was declined by fraud protection filters.3PayPal. Transaction Responses Hard declines prevent the merchant from incurring processing fees on likely fraud, but they also carry the highest risk of blocking a real customer.
A softer response routes the flagged transaction to a manual review queue, where a fraud analyst examines the data before deciding. That works for merchants with dedicated fraud teams but creates delays that may not suit time-sensitive products. Some merchants configure their systems to trigger 3D Secure authentication (the “Verified by Visa” or “Mastercard Identity Check” challenge) when velocity rules trip but the transaction isn’t clearly fraudulent. That shifts the verification burden to the cardholder’s bank, and if the cardholder completes the challenge, the transaction proceeds and fraud liability typically shifts to the issuing bank.
In severe cases, where patterns are consistent with automated bot attacks rather than a single suspicious customer, the system may temporarily blacklist a specific IP address, device fingerprint, or email. Visa specifically recommends that merchants add IP addresses with multiple failed payment attempts to a blacklist database for manual review.1Visa. Anti-Enumeration and Account Testing Best Practices These blocks typically last hours or days rather than permanently, to avoid locking out shared IP addresses used by offices or universities.
The False Decline Problem
Velocity checks calibrated too aggressively cause real damage: they reject legitimate customers. A parent buying school supplies for three kids in separate orders, a small business owner restocking from the same vendor multiple times in a day, someone whose first transaction failed because they mistyped their card number and tried again — any of these can trip a rule designed to catch a bot. Industry data suggests that roughly 1.5% of legitimate ecommerce transactions are incorrectly declined by automated fraud filters, and the total revenue lost to false declines across the industry runs into tens of billions of dollars annually.
The downstream damage goes beyond one lost sale. Studies consistently find that around 40% of customers who experience a false decline never return to that merchant. Even those who do come back tend to spend less per order afterward. A false decline can cost the entire future relationship with that customer, not just the value of the blocked transaction. This is why the U.S. Payments Forum warns against simple hard-decline velocity rules, noting that overly rigid thresholds force merchants into an impossible choice between raising limits to ineffective levels or scrapping the controls entirely.2U.S. Payments Forum. Velocity Checks
The better approach is graduated responses. Route lower-confidence flags to manual review or step-up authentication. Reserve hard declines for patterns that are unmistakably automated, such as 50 attempts from the same IP in two minutes, where no human explanation is plausible.
Why the Card Networks Expect Them
Velocity checks aren’t optional in practice. Card networks impose real financial penalties on merchants whose fraud and chargeback rates climb too high, and those penalties escalate fast. Merchants who fail to control card testing and fraud can end up in a monitoring program with monthly fines and, in extreme cases, lose their ability to accept card payments.
Mastercard’s Excessive Chargeback Merchant program triggers when a merchant exceeds 100 chargebacks and a 1.5% chargeback-to-transaction ratio in a single calendar month. Fines start at $1,000 per month in the second consecutive month above the threshold and escalate to $100,000 per month after 19 consecutive months. A higher tier kicks in at 300 chargebacks and a 3% ratio, with fines doubling at every level. Beyond the flat monthly assessment, Mastercard charges an additional $5 per chargeback above 300 once the merchant has been in violation for four or more months.4J.P. Morgan. Mastercard Excessive Chargeback Merchant Program Guide
Visa consolidated its fraud and dispute monitoring into a single program called the Visa Acquirer Monitoring Program (VAMP) in April 2025, with updated thresholds taking effect in 2026. VAMP calculates a combined ratio of fraud reports plus chargebacks divided by total monthly Visa sales. Visa also introduced an enumeration penalty specifically targeting card testing: merchants whose checkout traffic is 20% or more bot-driven testing face penalties even if no money was actually stolen.1Visa. Anti-Enumeration and Account Testing Best Practices Velocity checks and other anti-bot controls are treated as a baseline expectation.
Layering With Other Fraud Tools
Velocity checks catch patterns based on speed and repetition, but they’re blind to other fraud signals. A stolen card used once, from a clean IP, at a normal time of day will sail through without a flag. Velocity is one layer in a broader stack.
Address Verification Service (AVS) compares the billing address the customer enters against the address the issuing bank has on file. CVV verification confirms the customer has the three- or four-digit security code printed on the physical card. Neither catches high-speed automated attacks; that’s what velocity checks are for. But velocity checks won’t catch a fraudster who has a complete set of stolen card details and uses them carefully. Each tool covers a different blind spot.
Device intelligence platforms go deeper by analyzing the device itself: whether it’s on a VPN or proxy, whether the browser configuration matches the claimed location, whether the device has appeared in previous fraud attempts across other merchants. A third-party service that pools data across many merchants can see whether a card or device has been involved in fraud elsewhere, which no single merchant’s velocity database can.2U.S. Payments Forum. Velocity Checks
Visa’s anti-enumeration guidance recommends combining velocity thresholds with CAPTCHA controls, web application firewalls, session-level rate limiting, device fingerprinting, and 3D Secure authentication. The guidance also suggests injecting random pauses into the authorization flow for high-risk BIN ranges, which slows brute-force attacks that depend on processing speed.1Visa. Anti-Enumeration and Account Testing Best Practices
Data Storage and Compliance
Running velocity checks means storing transaction data (card numbers, IP addresses, device fingerprints, email addresses) in a way that allows real-time querying. Any entity that stores, processes, or transmits cardholder data falls under PCI DSS requirements, which impose technical and operational security standards on the environment where that data lives.5PCI Security Standards Council. Payment Card Data Security Standard (PCI-DSS) Merchants who build in-house velocity systems need to ensure their transaction logs and velocity databases meet PCI standards for encryption, access controls, and data retention. Many merchants sidestep this by relying on their processor or a third-party fraud platform to handle the data storage and velocity logic, keeping the sensitive data out of their own environment.
State privacy laws add another layer. Several states now classify IP addresses, device identifiers, and browsing behavior as personal information subject to disclosure requirements and consumer access rights. Most of these laws include exceptions for data collected and used specifically for fraud prevention, but the exception typically requires that the data actually be used for that purpose and not repurposed for marketing or analytics. Merchants who collect device fingerprints and behavioral data for velocity checks should ensure their privacy policies disclose the collection, even if the fraud prevention exception limits what consumers can do about it.