By E-commerce 4 Internet Marketers Editorial
Explainer. This guide walks website owners and developers who sell regulated or high-risk products through Authorize.net Advanced Fraud Detection Suite (AFDS) filters that matter most against card testing and enumeration. Facts below are attributed to Authorize.net Support Center AFDS, AVS, and Card Code Verification articles, Authorize.net merchant online help for AFDS filters and actions, and Visa’s publicly published Visa Acquirer Monitoring Program (VAMP) fact sheet when that PDF was fetchable. This is not legal, underwriting, or card-network advice. Authorize.net does not publish one-size-fits-all numeric velocity defaults in the docs cited here, so this article never invents vendor default thresholds. Any sample pattern is labeled as editorial interpretation that must be tuned to your own volume, vertical, and acquirer expectations.
Why card testing and enumeration matter for gateway fraud tools
Card testing is automated or manual probing of stolen or generated card data, often with many small attempts, rapid retries from one IP, mismatched address or card-code responses, and amounts that sit outside a normal catalog. Visa’s Visa Acquirer Monitoring Program fact sheet (2025) states that Visa monitors fraud, dispute, and enumeration levels monthly, and that VAMP requires acquirers to take proactive steps to prevent merchants from exceeding enumeration thresholds. The fact sheet defines a VAMP Enumeration Ratio as the count of enumerated authorization transactions (approved plus declined) divided by the count of authorization transactions (approved plus declined), with a threshold at or above 2000 basis points, and a VAMP Enumeration Transaction Count at or above 300,000 enumerated transactions (approved plus declined). Program threshold updates described in that sheet are effective 1 June 2025, with a program advisory period ending 30 September 2025.
Gateway-side AFDS rules cannot replace acquirer oversight or network programs. They are still among the first controls high-risk merchant IDs can tune when attackers hammer Authorize.net authorizations through a checkout or API.
What Authorize.net documents for AFDS
Authorize.net Support Center article KA-05469 (New Experience 2.0) describes Advanced Fraud Detection Suite as a set of rules-based transaction filters and IP address tools. Only an Account Owner can enable the product from Marketplace, Available Products, and fees vary by account (visible under Account, My Business, Products & Fees). In some cases AFDS is automatically enabled at account activation. The article also states that Authorize.net offers a Daily Velocity Filter at no charge in addition to the broader AFDS filter set.
Merchant online help for Advanced Fraud Detection Suite (AFDS) lists the same filter families. KA-05469 groups the card-testing-oriented tools under Card Testing Settings, then lists Daily Velocity, Hourly Velocity, Suspicious Transaction, and Transaction IP Velocity filters. Separate Transaction Settings cover Enhanced AVS Handling, Enhanced CCV Handling, and the Amount Filter. E-Commerce Settings cover Shipping Address Verification, IP Shipping Address Mismatch, Regional IP Address, and Shipping-Billing Mismatch. IP Address Administration covers Authorized API IP Addresses and IP Address Blocking.
Access path in New Experience 2.0 (per KA-05469) is Account and API Settings, then Advanced Fraud Detection Suite Settings, then Configure or Review Transactions.
Filter actions, severity, and review clocks
KA-05469 and the AFDS Filter Actions help page document four actions used by most filters:
- Process as normal and report filter(s) triggered (useful to test settings while still seeing hits in reports).
- Authorize and hold for review (authorize successfully, then place in Authorized/Pending Review; KA-05469 says you have 30 days to approve or void, or the transaction expires).
- Do not authorize, but hold for review (Pending Review before authorization; KA-05469 says you have 5 days to approve or decline, or the transaction expires).
- Decline the transaction (decline before authorization; documented as the most severe action).
If multiple filters fire with different actions, the most severe action wins. KA-05469’s example is a decline beating an authorize-and-hold outcome.
Merchant online help for the Enhanced AVS Handling Filter separately advises that when you use authorize-and-hold for AVS codes, you should approve or void held transactions within 72 hours. That is operational advice on the AVS filter page. It sits alongside the 30-day Authorized/Pending Review expiry window documented in KA-05469. Teams that hold aggressively need staffing for both clocks.
Merchant online help for the Suspicious Transaction Filter states that Authorize.net manages the criteria, that there are no custom settings, and that you cannot decline transactions triggered by this filter because it uses a more general set of criteria. Do not plan a hard-decline path for that filter alone.
Velocity patterns that curb bursts without inventing defaults
Authorize.net’s AFDS overview and filter configuration pages tell merchants who are unsure how to set Daily or Hourly Velocity to evaluate weekly or monthly volume and determine the average number of transactions likely in a day or hour. KA-05469 describes Daily and Hourly Velocity as thresholds for transactions per day or per hour, with excess volume handled by the chosen filter action. Neither page publishes a universal numeric default for those thresholds.
Editorial pattern (not a vendor default). Pull a few weeks of settled and declined authorization counts from production history, compute typical peak day and peak hour including legitimate promotions, then set Daily and Hourly Velocity above those peaks with headroom for growth. Start the action at process-and-report for a short observation window, then move burst outliers to authorize-and-hold or do-not-authorize hold once false positives are understood. Hard-decline at the storewide daily or hourly ceiling is documented as available, but it can cut off every legitimate buyer after a successful sales day, so many high-risk teams reserve decline for narrower filters.
Transaction IP Velocity is documented as a maximum number of transactions from the same IP address per hour. The AFDS overview states that multiple transactions that are part of the same order do not trigger this filter. KA-05469 and the AFDS overview both require the integration to pass customer IP (customerIP for the Authorize.net API, or x_customer_ip for AIM) or the filter cannot work. Configuration help also allows IP addresses that should not be filtered. Editorial pattern. Prefer IP velocity over storewide hourly decline when the attack signature is one botnet IP hammering cards. Whitelist known office, warehouse, or fulfillment IPs that legitimately submit many captures. If customerIP is missing in the cart or middleware, fix that before expecting AFDS IP tools to help.
Amount Filter against micro-auth and out-of-band tickets
KA-05469 places the Amount Filter under Transaction Settings and states that lower and upper amount thresholds help restrict high-risk transactions often used to test card number validity. Amounts below the lower limit or above the upper limit are handled per the selected action. Authorize.net warns merchants to be careful with the upper limit because carts of higher-priced items may be purchased together, and recommends searching history for the highest past amounts. Merchant online help adds that if you allow $0 authorizations, set the minimum to “0”, and adjust the maximum when products or services change.
Editorial pattern. If the catalog never sells sub-dollar items and you do not need $0 auths, a non-zero lower bound can catch penny and cent probing without touching normal SKUs. Keep the upper bound above documented historical peaks plus bundle headroom. Do not treat any specific dollar figure in this article as an Authorize.net default. None is published in the cited docs.
Enhanced AVS Handling without nuking conversion
Address Verification Service (AVS) compares billing address and ZIP to issuer data. Support article KA-04439 documents response codes including A, B, E, G, N, P, R, S, U, W, X, Y, and Z, and states that default basic gateway AVS rejection settings cover B, E, G, N, R, S, and U unless changed. KA-04439 notes that N (neither street nor ZIP match) is the most basic mismatch check, that Y should never be selected for rejection in ordinary setups, that U often appears for prepaid or gift cards so hard-rejecting U can create false declines, and that G, U, and S are not absolute blocks on international issuing banks.
AFDS Enhanced AVS Handling extends those codes with the four AFDS actions per code. Merchant online help recommends authorize-and-hold for codes B, E, R, G, U, S, and N, notes that N is typically a strong fraud indicator but can be legitimate after a move, warns against declining U when accepting branded gift or stored-value cards, and states that Y should usually be allowed. Billing address and ZIP must be required on the payment form for the filter to matter. Only one AVS code returns per transaction.
Editorial pattern for high-risk catalogs that still need conversion. Prefer authorize-and-hold (or process-and-report during tuning) for N and for unverified codes (B, E, R, G, U, S) instead of declining every imperfect AVS result on day one. Keep full matches (Y, and typically X) on allow. If you ship gifts regularly, avoid decline on shipping-billing mismatches and on U. Use Regional IP Address Filter when geography policy is the real control, because Authorize.net explicitly says G, U, and S are not absolutely effective for blocking non-U.S. traffic.
Enhanced CCV (CVV) Handling for card-code probing
Authorize.net uses Card Code Verification (CCV) for the three-digit or four-digit card security code. Support article KA-04440 documents codes M (match), N (does not match), P (not processed), S (should be on card but not indicated / blank), and U (issuer cannot process). The Enhanced CCV Handling Filter lets AFDS apply the four actions per code. Merchant online help requires the Card Code field on the payment form. KA-04440 warns that hard-declining P can create unexpected declines when processors map blank card-code submissions to Not Processed, and that American Express accounts without CID support should accept P and U rather than reject legitimate Amex traffic.
Editorial pattern. Decline or hold N mismatches when card code is required and reliably collected. Prefer hold or allow for P and U until you confirm processor and Amex behavior for your MID. Requiring card code without collecting it cleanly in Accept.js, Accept Hosted, or API payloads will manufacture S or P noise that looks like fraud but is integration debt.
Supporting ecommerce and IP filters that interact with testing
Documented companions that often fire during card-testing campaigns include Shipping Address Verification, IP Shipping Address Mismatch (needs customer IP and shipping address), Regional IP Address Filter (includes an unresolved region), Shipping-Billing Mismatch (needs both addresses; Authorize.net notes gift orders commonly mismatch), Authorized API IP Addresses (server allowlist for API submissions), and IP Address Blocking (block known bad customer IPs when customer IP is passed).
Editorial pattern. Hold shipping-billing mismatches for review rather than declining them if gift shipping is material to revenue. Use IP blocking for confirmed abusive sources after IP velocity has flagged them. Use Authorized API IP Addresses to stop attackers who found leaked API credentials and are posting from unexpected servers.
Practical checklist drawn from docs plus labeled interpretation
Enable AFDS (Account Owner) and open Advanced Fraud Detection Suite Settings. Confirm the cart or middleware sends customerIP (and shipping or billing fields your filters require). Require billing address, ZIP, and Card Code on the payment form when you intend to use Enhanced AVS and Enhanced CCV. Set Daily and Hourly Velocity from your own averages, not from invented vendor defaults. Configure Transaction IP Velocity with office or warehouse allowlists. Set Amount Filter bounds from catalog reality and history. Map Enhanced AVS codes with authorize-and-hold preferred for B, E, R, G, U, S, and N per Authorize.net’s AVS filter help, and keep Y allowed. Map Enhanced CCV so N is strict while P and U respect Amex and processor quirks. Start risky new actions on process-and-report, then graduate to hold, then decline only where false positives are rare. Staff the 5-day Pending Review and 30-day Authorized/Pending Review windows (and the 72-hour operational advice on the AVS hold page). Turn on Fraud Detection Suite per-suspicious-transaction email notifications, but do not rely on email alone. Review To Review and Suspicious queues in Manage Transactions. Re-check settings after catalog price changes, major campaigns, or acquirer VAMP conversations.
What this article omitted as unverified
Authorize.net fee amounts for AFDS (account-specific). Any claimed universal velocity or amount default numbers. Guarantees that AFDS alone keeps a merchant under VAMP enumeration thresholds. Conversion-rate percentages for any AVS or CVV action. Undocumented Suspicious Transaction Filter internals.