Authorize.Net Fraud Detection Suite: Filters and Settings That Work

Authorize.Net describes AFDS as "a set of powerful, rules-based transaction filters and Internet Protocol (IP) address tools." It's not a scoring service that guesses whether an order is fraud. You set the rules and the gateway applies them to every payment before it goes to your processor.

What it costs. Authorize.Net's feature page calls AFDS "included with every plan," and its pricing page, checked September 27, 2026, lists the monthly fee as $0.00. Its older support articles still say the cost "varies based on your specific account details." If you got your gateway through a provider, check the fee list in your account or ask your provider.

Check that it's on. Authorize.Net says AFDS is "in some cases" turned on when the account is activated. Don't assume. Only the Account Owner login can enable it:

• New experience (2.0): Marketplace, then Available Products, then Enable. Settings live under Account, then Account and API Settings, then Advanced Fraud Detection Suite Settings.
• Classic experience (1.0): click Advanced Fraud Detection Suite in the left menu, then Sign Up.

AFDS is one part of the Authorize.Net payment gateway. For what the rest of the gateway costs, see Authorize.Net pricing and fees.

Authorize.Net groups the filters by the job they do. Here they are in plain English, from its support articles (last modified July 17, 2025):

A few details from Authorize.Net that change how these work in practice:

• AVS and CVV settings. Address and card-code checks are standard gateway features. The AFDS versions add the choice to flag or hold on a result, not just accept or reject.
• IP filters need the customer's IP. IP velocity, IP-shipping mismatch and IP blocking only work if your site or cart sends the customer's IP address with each payment. Ask your developer or cart whether it does. Our Authorize.Net integration methods guide covers the connection options.
• Shipping-billing mismatch needs both addresses. Your payment form has to collect both, or the filter has nothing to compare. Authorize.Net also notes that mismatches "are common with gift transactions."
• Upper amount limits catch big real orders too. Authorize.Net suggests checking your highest past orders before you set one.

Nothing on Authorize.Net's AFDS pages describes device fingerprinting or machine-learning scores. If you need those, they come from a separate fraud service.

Every filter gets one of four actions. Here's what each does, per Authorize.Net's support articles:

The most severe action wins. If one payment trips two filters, say one set to decline and one set to hold, it's declined.

Hold or decline? Decline when a signal is almost never a real customer. Hold when real customers trip it sometimes, like a shipping-billing mismatch on a gift. A hold costs you staff time. A wrong decline costs you the sale and maybe the customer. Use "hold without authorizing" when you expect a lot of junk, since Authorize.Net says it avoids "any associated authorization fees."

These are general starting points, not rules from Authorize.Net. Your numbers should come from your own order history. Whatever you pick, run it on "process and report" for a week or two, see what it would have caught, then switch to hold or decline.

If most of your payments come in by phone, see how the Authorize.Net virtual terminal handles keyed-in orders and address checks. Subscription billers should read our Authorize.Net recurring billing guide before setting daily limits, so a busy renewal day isn't flagged.

A hold only helps if someone looks at it. Authorize.Net's rules:

• Authorized/Pending Review: approve or void within 30 days. After that it's "marked as Expired and isn't available for settlement," so you don't get paid.
• Pending Review (not yet authorized): approve or decline within 5 days, or it expires the same way. Approving sends it for authorization then.
• Declines and voids are final. To charge the customer later, you enter a new transaction.

Held payments are listed under Suspicious Transactions (classic) or Review Transactions in the AFDS settings (new experience). You can also turn on an email for each suspicious transaction. Authorize.Net warns those emails "should not be your sole source" of status updates.

Our advice: check held transactions every business day, and don't ship a held order until it's approved. When you review one, look at whether the address, card code and IP line up and whether the order looks like your normal customer's. Our guide to the signs of card-not-present fraud lists what to look for. If in doubt, call or email the customer using details from your records, not ones typed into the order.

Card testing is when a bot runs stolen card numbers through your checkout, often with tiny amounts, to find which ones work. You see a burst of small payments, most of them declined. Even the declines can cost you: the Gateway Only plan on Authorize.Net's pricing page charges its per-transaction fee on "charges, refunds, voids and declines."

Authorize.Net groups its velocity filters under "Card Testing Settings." Use them together with fixes on your own site:

1. Set hourly and daily velocity limits a little above your busiest real hour and day. Set them to hold or decline.
2. Turn on transaction IP velocity with a low limit per hour. Make sure your cart sends the customer's IP, or this filter can't work.
3. Set a lower amount limit if you never sell anything for a dollar or two. Authorize.Net says the amount filter targets transactions "often used to test the validity of credit card numbers."
4. Lock down your API. If your site connects by API, list your server IPs under authorized API IPs. Authorize.Net rejects API transactions from any other address.
5. Add a CAPTCHA to checkout. This is a site-side fix, not part of AFDS. Ask your cart or developer.
6. Limit payment attempts in your cart, per session or per customer, if your cart allows it.

If an attack is under way, block the IPs it comes from, then look at your settled batch for any tested cards that got through. Refund those before they become disputes.

No single set of payment fraud prevention tools covers everything. AFDS screens payments on the way in. It doesn't help with:

• Friendly fraud. A real cardholder who buys, then disputes the charge, passes every filter. Clear policies and receipts help more here.
• Disputes and chargebacks. AFDS doesn't answer disputes or send alerts. Visa and Mastercard both watch how many fraud reports and disputes you get. See chargeback ratio limits for the current thresholds and alert tools. Authorize.Net's pricing page lists a $0 gateway fee for card chargebacks, but your merchant account has its own chargeback fee.
• Your website. Refund policies, descriptors and delivery tracking sit on your side. Our chargeback prevention checklist covers them. So does PCI compliance.
• Trust badges. The Authorize.Net Verified Merchant Seal is being retired. See what to do about the seal below.

The Verified Merchant Seal was a badge merchants could add to their website or payment form to show shoppers they took payments through Authorize.Net. Authorize.Net's support article 000001527 (last modified September 14, 2026) says the seal "is being retired and discontinued as part of an upgrade to the newest Authorize.net experience." It tells merchants: "If you have already set up and enabled the VMS on your website or payment form, remove and disable it." The article gives no shutdown date.

What to do now:

• Remove the seal code from your site templates and payment form, so shoppers don't see a broken or blank badge.
• Don't swap in a look-alike badge. A seal nobody verifies doesn't stop fraud, and a fake one can hurt trust.
• Build trust in ways that also cut disputes: a secure (HTTPS) checkout, a hosted payment form such as Accept Hosted, clear contact details and a visible refund policy.

The seal was a trust signal, not a fraud tool, so retiring it doesn't change your AFDS filters.