Authorize.net Card Inspection: CVV, AVS and Fraud Filters

Authorize.net card inspection is the check the gateway runs on a card during a transaction: the card code (CVV/CVN), the billing address through AVS, and the rules in the Fraud Detection Suite. The result decides whether an order is approved, held for review, or declined. It is a merchant-side risk tool, not proof that the buyer owns the card.

Authorize.Net Card Audit: A Comprehensive Guide

What does card inspection mean inside Authorize.net?

The phrase covers three things merchants often lump together. First is data capture: the gateway collects the card number, expiration date, card code, and billing address at checkout. Second is verification: Authorize.net sends those values to the issuer as part of the authorization request. Third is filtering: the Fraud Detection Suite scores the order and applies the rules you set.

authorize.net card evaluation

All of it happens before settlement. Nothing in the process moves money. An approval means the issuer set aside the amount, and a capture moves it later.

more on this topic

How does Authorize.net check a card during a transaction?

1. The customer enters card details on your checkout page, hosted payment form, or Virtual Terminal.
2. The gateway validates the format: Luhn check on the number, an expiration date in the future, and a card code length that matches the brand.
3. Authorize.net sends an authorization request to the processor and the issuing bank with CVV and AVS data attached.
4. The issuer returns an approval or decline, plus a card code result and an address verification result.
5. The Fraud Detection Suite compares the order against your filter settings and adds a hold or a reject if a rule trips.
6. Your system receives the response and you capture, void, or flag the order for review.

Format checks stop obvious typing errors. They do not tell you whether the number is live. Only the issuer response does that.

What do CVV and AVS result codes tell you?

A card code result comes back as a single letter. M means the code matched, N means it did not, P means it was not processed, S means it should have been on the card but was not sent, and U means the issuer could not verify it.

AVS returns a separate letter for the street address and ZIP. Y means both matched. A means only the street matched, Z means only the ZIP matched, N means neither matched, and U means the issuer does not support the check.

A card code mismatch combined with an address mismatch is a strong warning sign. A card code match on its own is weak evidence, because issuers in some countries do not enforce CVV checks at all.

Which fraud filters can a merchant turn on?

• Address Verification System filter: rejects or holds orders when the street and ZIP both fail.
• Card code filter: rejects orders when the CVV does not match, with a separate setting for missing codes.
• Velocity filters: cap the number of transactions per card, per IP, or per time window.
• Amount filters: flag orders above a threshold or orders where the authorized amount differs from the settled amount.
• Country and IP filters: block transactions from regions you do not ship to, or from known bad addresses.
• Free email filter: holds orders placed with throwaway email domains.
• Transaction IP velocity: catches one address trying many cards in a short span.

Filters work as a stack. Each rule adds a score, and you set the score at which an order is rejected, held, or allowed through. Start with wide thresholds and tighten them once you know your normal decline rate.

Why do card-testing attacks show up in gateway accounts?

Card testers submit small charges to find out which numbers are still open. The patterns are easy to spot once you know them: a burst of low-value transactions, a high decline rate, one IP address cycling through many card numbers, or card numbers that run in sequence.

These attacks cost real money. Every attempt carries a per-transaction fee, a high decline rate can hurt your merchant account standing, and processors may place a hold on your account while they review the activity. Most attacks stop once velocity limits and a required card code are in place.

How do you reduce card-testing risk on Authorize.net?

1. Require the card code on every order and reject mismatches rather than just flagging them.
2. Turn on per-IP and per-card velocity limits, starting at a low number such as three attempts per hour.
3. Use hosted payment fields or tokenization so card data never touches your server.
4. Add a CAPTCHA or bot check to the checkout form.
5. Block countries you do not serve, and review the IP country field on every manual order.
6. Watch your decline ratio each week. A sudden jump is the earliest signal of an attack.

What can card inspection not do?

It cannot prove the buyer is the cardholder. A passing AVS and CVV check only means the data matched what the issuer has on file, and a fraudster with stolen data often has both.

It also does not cover chargebacks from friendly fraud, where the real cardholder disputes a charge after delivery. Those arrive weeks later and need order tracking, delivery confirmation, and clear refund policies to fight. And it does not verify that funds exist beyond the amount held at authorization.

Does Authorize.net store the card code after a transaction?

No. PCI rules bar merchants and processors from storing the CVV after authorization, so the code is used once and discarded. Card numbers can be stored only as a token or in a PCI-validated vault. That is why recurring billing relies on tokens and customer profiles rather than re-sending the code.

Is card inspection included in the gateway fee?

The verification tools and fraud filters come with the Authorize.net account. The cost sits in the per-transaction fees charged by your merchant account provider, plus any monthly gateway fee. Ask your provider which rate applies to declined authorizations, since card-testing attacks generate a lot of them.