AVS and CVV settings verify a billing address and a card’s security code against issuer records, then feed those results into your approval decision. The right posture: turn both checks on, log every response code, and never set them to auto-decline on a partial match. Use transaction-level overrides for trusted or recurring customers, and never store CVV data after authorization since PCI DSS bars it outright.

TL;DR:

  • Most authorization responses override AVS and CVV match results, so declines should not be based solely on address or security code mismatches.
  • Response codes vary across issuers and acquirers, making it essential to log raw codes and evaluate risk based on the specific match level and transaction size.
  • Common mismatches often stem from address formatting issues; normalization and manual review of unsupported or unavailable codes improve accuracy.
  • PCI DSS prohibits storing CVV data after authorization, requiring systems to purge this data immediately to maintain compliance.
  • Tiered decision models and transaction-level overrides, especially for recurring or trusted customers, help balance fraud prevention with revenue retention.
Davincipay
Build More Reliable Payment Decisions
DavinciPay.ai helps complex online businesses manage payment gateways, fraud prevention, chargeback mitigation, and specialized acquiring relationships.
Explore payment solutions

Table of Contents

What Are AVS CVV Settings and How Do They Work During Authorization?

AVS compares the billing street number and ZIP code a customer enters against what the card issuer has on file. CVV checks the three or four digit security code printed on the card, confirming the person entering it likely holds the physical card. Neither check happens in isolation. Both ride along inside the same authorization request your gateway sends to the card network, and the issuer returns a single approval or decline alongside separate AVS and CVV result codes.

Here’s the detail merchants miss: the authorization decision itself always overrides the AVS/CVV result. Visa’s own guidance for card acceptance states that authorization responses take precedence over AVS or CVV results, so you should never process a transaction the issuer declined just because the address matched.

  • AVS sends billing street and ZIP for comparison against issuer records.
  • CVV checks the card’s printed security code against the issuer’s stored value.
  • The issuer returns one authorization decision plus separate AVS and CVV codes.
  • API fields like checkAVS (Y/N) and ignoreAvsResult let you override account defaults per transaction.
  • A zero-amount authorization can verify a card and billing details before you charge anything.

Most gateways also support zero-dollar verification, a pre-authorization check that confirms a card is live and the AVS/CVV match before real money moves. It’s a useful tool for subscription merchants validating a card on file without triggering a charge.

How Do You Read Common AVS and CVV Response Codes?

Response codes fall into four practical buckets: full match, partial match, no match, and unavailable or unsupported. Treating them all the same is the single biggest driver of unnecessary declines.

A full match, often returned as code X or Y depending on the processor, means both street and ZIP matched. A partial match, commonly A or P, means only the address or only the ZIP matched, not both. A no match, N or F, means neither matched. An unsupported or unavailable result, often S or U, means the issuer couldn’t perform the check at all, which is a technical gap, not evidence of fraud.

  • Full match (X/Y): approve under normal risk rules.
  • Partial match (A/P): flag for review or request secondary verification, don’t auto-decline.
  • No match (N/F): weigh heavily against approval, especially on higher-value orders.
  • Unsupported/unavailable (S/U): treat as unknown, not as a red flag.

Here’s the catch: the exact letters and their meanings vary by issuer and acquirer, so the raw code your gateway shows may not map identically across processors. JPMorgan Chase’s guidance on verification codes confirms mapping differences exist across issuers and regions, which is exactly why merchants need to log raw codes rather than just the pass/fail summary their dashboard shows. Tie your default action to both the code and the order value: a small partial match carries very different risk than a large one.

Where Do You Configure AVS and CVV Settings: Account vs Transaction Level?

Most gateways split AVS/CVV controls into two layers, and confusing them is where merchants get into trouble. Account-level settings live in your payment portal and apply globally: decline on any mismatch, decline when AVS is unavailable, or check only ZIP versus full street address. Transaction-level settings override those defaults for a single order, through API fields passed at the time of the charge.

  1. Confirm with your processor which override fields it actually supports, since not every gateway exposes the same controls.
  2. Test configuration changes in a sandbox environment before touching live traffic.
  3. Add logging for every AVS/CVV response code before you turn on any strict auto-decline rule.
  4. Use checkAVS (Y/N) to control whether address data gets sent at all, separate from ignoreAvsResult, which sends the data but tells your system to ignore the result during decisioning.
  5. Reserve per-transaction overrides for recurring billing, vetted repeat customers, or zero-amount verification calls.

That distinction between “not sending AVS” and “sending it but ignoring the result” matters more than it sounds. Visa Acceptance Support Center notes that gateways can expose both options separately, and choosing wrong affects what data shows up later in dispute and chargeback records.

Pro Tip: Start every new AVS/CVV rule in “log only” mode for two to four weeks before switching it to auto-decline. You’ll catch false-decline patterns before they cost you real revenue.

Best Practices for Tuning AVS/CVV Without Losing Good Orders

Binary approve/decline logic is where most merchants lose money. A tiered model, approve, review, or decline, based on transaction amount, AVS/CVV result, device and IP signals, order velocity, and 3-D Secure status, catches more fraud while letting more legitimate orders through.

  • Route partial AVS/CVV matches to manual review or a secondary verification step instead of an automatic decline.
  • Track false-decline rates and fraud-loss rates side by side, then adjust thresholds based on what the numbers actually show, not gut instinct.
  • Layer in 3-D Secure for higher-risk orders since it shifts liability toward the issuer and gives you stronger authentication evidence.
  • Combine AVS/CVV with device fingerprinting, IP geolocation, and velocity checks rather than relying on card data checks alone.

Sift’s research on AVS and CVV verification makes the case plainly: these checks work best as one layer in a broader fraud strategy, not as a standalone gate. Merchants running supplement subscriptions or telehealth recurring billing see this constantly, a legitimate repeat customer moves, gets a new card, or types a ZIP wrong, and a rigid rule blocks a good order that a risk score would have cleared.

Pro Tip: If you process EMV 3DS transactions, make sure your gateway includes the issuer-generated CAVV value in the authorization request. Without it, you lose the authentication evidence that 3DS is supposed to provide.

Fixing AVS and CVV Mismatches Before They Cost You Sales

Most AVS mismatches trace back to formatting, not fraud. “123 Main St Apt 4” and “123 Main Street #4” can trigger a mismatch even when the customer typed their real address correctly.

  1. Normalize address fields before submission, standardizing abbreviations like St., Ave., and Apt. so formatting quirks stop triggering false mismatches.
  2. Treat unavailable or unsupported codes (U, S) as a technical gap, not a fraud signal, and route them to manual review rather than an automatic decline.
  3. Give customer service a script for safe re-authorization: confirm the billing address matches the card statement exactly, then retry rather than asking for a different card first.
  4. Escalate to your acquirer when a specific issuer consistently returns unsupported codes, since that often points to an integration issue rather than a one-off decline.

MaxMind’s guidance on AVS and CVV declines backs the normalization approach directly, framing it as a conversion fix, not just a fraud-prevention tactic. If you sell internationally, expect more unsupported codes by default, since AVS support outside the U.S. and Canada is far less consistent.

What PCI Rules Govern AVS and CVV Data Handling?

PCI DSS Requirement 3.2 forbids storing CVV or CVC values after authorization completes, full stop. That includes encrypted storage that could technically be decrypted later. The PCI Security Standards Council’s FAQ on CVC storage states this without exception, meaning your systems need to discard that data the moment authorization returns.

  • Design your checkout and gateway integration to purge CVV data immediately after the authorization response.
  • Route card data through PCI-compliant processors or tokenization to keep raw card numbers off your own servers entirely.
  • Use PCI-validated terminals and point-to-point encryption (P2PE) where hardware is involved.
  • Ask any new vendor directly how they handle SAD (sensitive authentication data) retention before signing.

The PCI Small Merchant Guide to Safe Payments recommends outsourcing to compliant providers specifically because it shrinks your own PCI scope. Fewer systems touching card data means fewer systems you’re responsible for auditing.

What High-Risk Merchants Get Wrong About AVS and CVV Tuning

Most guides treat AVS/CVV like a simple on/off switch. In practice, the merchants who get burned worst are the ones running blanket decline rules across every product line, treating a $25 supplement trial order the same as a $400 telehealth consult. Those orders carry entirely different risk profiles and deserve different thresholds.

Different risk thresholds for order types

Transaction-level overrides earn their keep with recurring billing. A customer on their eighth monthly shipment who fails AVS because they moved apartments shouldn’t get the same treatment as a first-time order from an unfamiliar IP address. That’s exactly the scenario where an override, backed by order history, belongs.

The checklist I’d hand any merchant tuning these settings for the first time: test in sandbox, log everything before you decline anything, tune thresholds against real approval and fraud data, then escalate persistent code mismatches to your acquirer instead of guessing at fixes.

— Peter

Get Hands-On Help Configuring AVS and CVV for High-Risk Accounts

Tuning AVS/CVV rules correctly takes time most merchants don’t have, especially when you’re also managing underwriting, chargeback ratios, and processor relationships, so following recommended push payment fraud prevention steps for businesses is critical. A specialized payment processor can integrate fraud prevention and PCI-compliant gateway features to provide a unified platform, so you’re not stitching together settings across multiple dashboards.

Davincipay

That means transaction-level controls configured correctly the first time, chargeback mitigation tools that work alongside your AVS/CVV rules instead of against them, and support that actually understands why a supplement subscription merchant needs different thresholds than a telehealth clinic. Whether you’re running nutraceuticals payment processing, supplements payment processing, or telehealth payment processing, the underwriting and gateway setup accounts for your specific risk profile from day one. If your current processor left you guessing at AVS/CVV defaults, apply now and get a setup built around your actual transaction mix.

Where to Verify AVS and CVV Rules Directly

Where to Verify AVS and CVV Rules Directly — overview diagram

For exact API fields and card-brand rules, consult Visa’s AVS management guidance and the PCI Council’s CVC storage FAQ.

Sources

FAQ

What Does “Do Not Honor Due to AVS CVV Settings” Mean?

This decline message means the issuer flagged a mismatch on the billing address, security code, or both, and your account’s rules were set to decline on that result. It doesn’t always mean fraud. Formatting differences, an outdated billing address, or an unsupported issuer response can all trigger it even on a legitimate order.

What Is the AVS CVV Setting, Exactly?

It’s the configuration in your payment gateway or processor account that controls how strictly you require the billing address (AVS) and card security code (CVV) to match issuer records before approving a transaction. You can set it at the account level for all transactions or override it per transaction using API fields like checkAVS.

What Are AVS Settings Supposed to Control?

AVS settings determine whether your account sends a customer’s billing street and ZIP code to the issuer for comparison, and what your system does with the result: approve, flag for review, or decline. Visa’s guidance on AVS management confirms gateways typically separate the option to skip sending AVS data entirely from the option to send it but ignore the result.

How Do You Fix an AVS Mismatch?

Start by normalizing the address format, checking for abbreviation differences like “St.” versus “Street” or missing apartment numbers. If the mismatch persists, treat unsupported or unavailable codes as unknown rather than automatic red flags, and route genuine no-match results to manual review instead of an instant decline.

Does Davincipay Help Configure AVS and CVV Rules?

Yes. Some high-risk payment processing providers include gateway integration and fraud prevention tools designed to support transaction-level AVS/CVV controls alongside chargeback mitigation, tailored to regulated verticals like telehealth and nutraceuticals. Current setup details are available by applying directly on the Davincipay site.