# AVS & CVV
Source: https://paymentsandrisk.com/docs/fraud/prevention/avs-cvv

Last updated 23 October 2026.

TL;DR

-   **AVS**: Checks billing address vs. issuer records. Y=full match (accept), N=no match (review/decline), U/G=unavailable (use other signals)
-   **CVV**: Verifies the card code. A match is useful, but doesn't prove the buyer has the physical card
-   **Neither shifts liability.** For liability shift, use [3D Secure](https://paymentsandrisk.com/docs/fraud/prevention/3ds/)
-   **Don't hard-decline AVS mismatches blindly**: real customers can fail because of formatting, moves or issuer quirks
-   **Test first**: choose a shadow period and error budget, then wait for outcomes before enforcing

If you just take cards and don't run your own fraud rules

You need two settings, both in your processor dashboard and both usually on by default: **require CVV** for online payments, and **turn on AVS**. Don't auto-block AVS mismatches - customers move, typo their zip, or use work addresses, and you'll block real sales. That's it. The rest of this page is for teams tuning their own decline rules.

AVS checks if billing address matches what the [issuer](https://paymentsandrisk.com/docs/fraud/issuer-perspective/) has. CVV verifies the 3-4 digit code on the physical card.

Neither is foolproof and neither shifts [liability](https://paymentsandrisk.com/docs/fraud/reference/emv-liability/). They just help you make a better [authorization decision](https://paymentsandrisk.com/docs/fraud/detection/authorization-decisioning/) about which transactions to accept. If it's liability shift you want, that's [3D Secure](https://paymentsandrisk.com/docs/fraud/prevention/3ds/).

Don't Hard-Decline on AVS Mismatch Until You've Measured

Legitimate customers can fail AVS on formatting differences, recent moves or issuer quirks. Measure that share on your own payments before blocking orders.

Experiment to Run

**Before enforcing any AVS rule:**

1.  Run in shadow mode first (flag but don't block)
2.  For each flagged transaction, check the later fraud outcome and any confirmed legitimate order
3.  Keep unresolved outcomes unknown until enough follow-up has passed

**Decision rule:** Choose the fraud precision and legitimate-sales-loss limits before the test. Tune them to your margin and capacity; these aren't network rules. A short shadow run alone won't settle delayed fraud outcomes.

## AVS + CVV Decision Flow

```mermaid
flowchart TD
    A[Transaction<br/>Received] --> B{CVV<br/>Match?}
    B -->|No Match| C[Decline]
    B -->|Match| D{AVS<br/>Result?}
    B -->|Not Provided| E[Higher Risk<br/>Add to Score]
    D -->|Y or X| F[Low Risk<br/>Accept]
    D -->|A or Z| G[Medium Risk<br/>Check Other Signals]
    D -->|N| H[High Risk<br/>Review or Decline]
    D -->|U, G, S| I[Unknown<br/>Use Other Signals]
    G --> J{Other Signals<br/>OK?}
    J -->|Yes| F
    J -->|No| H

    style C fill:#b42318,color:#fff
    style F fill:#1f6f4a,color:#fff
    style H fill:#9a5b00,color:#fff
```

## Address Verification Service (AVS)

### How AVS Works

1.  Customer enters billing address at [checkout](https://paymentsandrisk.com/docs/payments/checkout-conversion/)
2.  Your [processor](https://paymentsandrisk.com/docs/operations/processor-management/) sends address data to card network
3.  [Issuer](https://paymentsandrisk.com/docs/fraud/issuer-perspective/) compares submitted address to their records
4.  AVS response code returned in the [authorization response](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/)
5.  You decide: accept, [decline](https://paymentsandrisk.com/docs/reference/decline-codes/), or review

### AVS Response Codes

| Code | Meaning | Risk Level | Recommendation |
| --- | --- | --- | --- |
| **Y** | Full match (address + zip) | Low | Accept |
| **X** | Full match (9-digit zip) | Low | Accept |
| **A** | Address matches, zip doesn't | Medium | Review or accept with CVV match |
| **Z** | Zip matches, address doesn't | Medium | Review or accept with CVV match |
| **N** | No match | High | Decline or manual review |
| **U** | Issuer doesn't support AVS | Unknown | Use other signals |
| **R** | Retry (system unavailable) | Unknown | Retry or use other signals |
| **S** | AVS not supported for card type | Unknown | Use other signals |
| **G** | International card (non-US issuer) | Unknown | Use other signals |

### AVS Limitations

**Geographic coverage:**

-   Strong support: US, Canada, UK
-   Limited/no support: Most other countries (see [going global](https://paymentsandrisk.com/docs/payments/going-global/))
-   [International cards](https://paymentsandrisk.com/docs/payments/payment-methods/international/) often return "G" or "U"

**Formatting issues:**

-   "123 Oak St" vs "123 Oak Street" may not match
-   Apartment numbers handled inconsistently
-   PO boxes may fail
-   Recent moves not yet updated with issuer

* * *

## International AVS: What Works Outside the US

AVS was designed for US addresses. International transactions require a different approach.

### AVS Support by Region

| Region | AVS Support | Notes |
| --- | --- | --- |
| **United States** | Full | Street number + zip |
| **Canada** | Full | Street number + postal code |
| **United Kingdom** | Full | Numeric portion of address + postcode |
| **Western Europe** | Partial | Varies by country and issuer |
| **Latin America** | Limited | Most return U/G |
| **Asia Pacific** | Limited | Japan/Australia have some support |
| **Other** | Minimal | Expect U/G responses |

### Response Code Reality for International

| Response | What It Means | What to measure |
| --- | --- | --- |
| **G** | International issuer result | Its share in your processor's response mapping |
| **U** | Unavailable | Its share by country and issuer |
| **S** | Service not supported | Its share by card and country |
| **Y/A/Z** | Match or partial-match data | Its share and later outcomes |

### International AVS Strategy

**Don't:** Decline all G/U responses without checking what your processor means by them and how many legitimate orders you'd block

**Do:** Layer additional verification for international transactions

| Signal | Use For International |
| --- | --- |
| **CVV** | Always require (still works internationally) |
| **[3DS](https://paymentsandrisk.com/docs/fraud/prevention/3ds/)** | Strongly recommended (liability shift) |
| **Email verification** | Check for free/disposable emails (see [identity verification](https://paymentsandrisk.com/docs/fraud/detection/identity-verification/)) |
| **Phone verification** | Consider SMS verification for high-value |
| **Shipping address analysis** | Freight forwarders, PO boxes, known [fraud](https://paymentsandrisk.com/docs/fraud/types/third-party/) addresses |
| **[Device fingerprint](https://paymentsandrisk.com/docs/fraud/detection/device-fingerprinting/)** | Works regardless of location |

### UK-Specific AVS

UK AVS checks:

-   Numeric part of building number/name
-   Numeric part of postcode

**Example:** "Flat 42, 15 High Street, London SW1A 2AA"

-   Checks: 42, 15, 1, 2 (numerics extracted)
-   Different from US format

### International Risk Framework

Illustrative starting points below, not network amount requirements. Tune them to margin and observed risk.

| Transaction Value | G/U Response | Recommended Action |
| --- | --- | --- |
| Low (<$50) | G or U | Accept with CVV match |
| Medium ($50-200) | G or U | Accept with CVV + 3DS |
| High ($200+) | G or U | 3DS required + manual review |

### Country-Specific Considerations

| Country | Notes |
| --- | --- |
| **Germany** | Privacy laws limit AVS; use 3DS |
| **France** | AVS rarely supported; 3DS common |
| **Japan** | Limited AVS; 3DS well-adopted |
| **Australia** | Moderate AVS support |
| **Brazil** | CPF (tax ID) more useful than AVS |

International Best Practice

For international transactions, treat CVV + 3DS as your primary fraud prevention. AVS is a bonus signal, not a gatekeeper.

### Finding Your AVS Thresholds

Those generic "decline on N" recommendations are someone else's guess. Here's how to find yours:

**Backtest experiment:**

1.  Pull last 30 days of transactions
2.  Apply proposed rule in shadow mode
3.  Calculate: What % would have been blocked? What % of those were actually fraud?

If the rule would block 2% of all transactions and 10% of that flagged set is confirmed fraud, the remaining flagged share is 2% x 90% = 1.8% of all transactions. That's not 1.8% of legitimate customers; the denominator differs. Don't call unresolved orders legitimate.

**Decision rule:** Choose the fraud precision and legitimate-sales-loss limits before the test. Tune them to your margin and capacity; these aren't network rules. A short shadow run alone won't settle delayed fraud outcomes. Enforcing is a live change, so give it an owner, a loss cap and an outcome window first ([before any live test](https://paymentsandrisk.com/docs/reference/experimentation/#before-a-live-test)).

### AVS Rules by Transaction Type

| Transaction Type | Suggested Starting Point | How to Test |
| --- | --- | --- |
| Physical goods, domestic | Require Y/A/Z, decline N | Shadow mode 2 weeks, measure FP rate |
| Physical goods, international | Accept U/G with CVV match | Compare fraud rates U/G vs. Y |
| Digital goods | Accept with CVV match regardless | Monitor for abuse patterns |
| High-value orders | Require Y + CVV + additional verification | Lower threshold, more review |
| Recurring/saved cards | AVS not available | Use other signals |

## Card Verification Value (CVV)

### How CVV Works

1.  Customer enters CVV at checkout
2.  Processor sends CVV to issuer
3.  Issuer verifies CVV matches card records
4.  Response: match/no match/not processed

### CVV Response Codes

| Code | Meaning | Action |
| --- | --- | --- |
| **M** | Match | Accept (good signal) |
| **N** | No match | Decline |
| **P** | Not processed | Use other signals |
| **S** | CVV should be on card but wasn't provided | Request CVV |
| **U** | Issuer doesn't support CVV | Use other signals |

### Why CVV Matters

**A match checks the code, not the person:** The code can be stolen with the card number. Visa describes CVV2 as a static code that can be compromised, so it provides a signal rather than proof of physical possession. NETWORK [Visa's Click to Pay guide](https://developer.visa.com/docs/visa-secure-remote-commerce/introduction-to-visa-click-to-pay-api), checked 22 October 2026.

**For [compelling evidence](https://paymentsandrisk.com/docs/chargebacks/representment/compelling-evidence/):** Match the evidence to the dispute condition. CVV alone isn't a universal qualifying requirement.

**Cannot be stored:** [PCI DSS](https://paymentsandrisk.com/docs/compliance/pci-dss/) prohibits storing CVV after authorization. [Recurring transactions](https://paymentsandrisk.com/docs/payments/subscriptions-recurring/) can't re-verify CVV.

### CVV Best Practices

**Do:**

-   Require CVV on all first-time transactions
-   Re-request CVV when shipping address changes
-   Re-request CVV from unrecognized devices
-   Decline CVV mismatches on CNP (online and phone) orders

**Don't:**

-   Store CVV (PCI violation)
-   Skip collection because "it's extra friction"
-   Assume CVV match = legitimate (can be compromised with card)

## Combining AVS and CVV

| AVS Result | CVV Result | Risk | Recommendation |
| --- | --- | --- | --- |
| Y (full match) | M (match) | Low | Accept |
| Y | N | Medium-High | Decline or review |
| A or Z (partial) | M | Medium | Accept with monitoring |
| A or Z | N | High | Decline |
| N | M | Medium-High | Review (fraudster may have CVV but not address) |
| N | N | Very High | Decline |
| U/G (unavailable) | M | Medium | Accept with additional signals |
| U/G | N | High | Decline |

This is a Bet

Every threshold you set is a tradeoff: blocking more fraud vs. blocking more good customers.

Your optimal thresholds depend on:

-   Your [fraud rate](https://paymentsandrisk.com/docs/fraud/metrics/) (high fraud = tighter thresholds are worth it)
-   Your margin (low margin = false positives hurt more)
-   Your customer base (international customers hit AVS limits)

There's no universal right answer. Test and measure.

## Beyond AVS/CVV

AVS and CVV are table stakes. They're necessary but not sufficient. Modern fraud prevention layers additional signals:

-   **3D Secure:** Shifts liability to issuer for authenticated transactions
-   **Device fingerprinting:** Identifies returning devices, detects anomalies
-   **Behavioral analytics:** Analyzes how customers interact with your site
-   **Velocity rules:** Flags unusual patterns (many orders, same card, short time)
-   **Risk scoring:** ML models that combine all signals into a single score

See [Risk Scoring](https://paymentsandrisk.com/docs/fraud/prevention/risk-scoring/) for how these signals combine.

## Processor Configuration

Illustrative configuration only. Check your processor's result mapping and tune the $100 amount before enforcing:

```text
IF cvv_result = "N" THEN decline
IF avs_result = "N" AND amount > 100 THEN decline
IF avs_result IN ("A", "Z") AND cvv_result = "M" THEN accept
IF avs_result = "U" AND card_country != "US" AND cvv_result = "M" THEN accept
```

Where Experiments Lie to You

-   **Selection bias:** If you only look at declined transactions, you don't know how many good customers you blocked
-   **Lag time:** Fraud can arrive after your shadow test ends. Use the follow-up window in your own records and keep unresolved outcomes unknown.
-   **Fraudster adaptation:** Tighten AVS rules and the good fraudsters just start using correct addresses. Measure total fraud, not the AVS-flagged slice, or you won't see it move.

## Impact on Chargebacks

**For [representment](https://paymentsandrisk.com/docs/chargebacks/representment/):**

-   AVS match is often required to fight [fraud chargebacks](https://paymentsandrisk.com/docs/reference/reason-codes/visa/10-4-fraud-cnp/)
-   CVV match strengthens your case against [friendly fraud](https://paymentsandrisk.com/docs/fraud/types/friendly-fraud/)
-   Without either, you may not qualify to represent under [network rules](https://paymentsandrisk.com/docs/compliance/network-rules/)

**For [Visa CE 3.0](https://paymentsandrisk.com/docs/chargebacks/representment/compelling-evidence/):**

-   Check matching IP, device, full delivery address and customer account data
-   AVS and CVV results don't replace those required matching elements

## Next Steps

**Just starting with AVS/CVV?**

1.  [Understand response codes](https://paymentsandrisk.com/docs/fraud/prevention/avs-cvv/#avs-response-codes) - What each code means
2.  [Test your thresholds](https://paymentsandrisk.com/docs/fraud/prevention/avs-cvv/#finding-your-avs-thresholds) - Backtest before enforcing
3.  [Check CVV requirements](https://paymentsandrisk.com/docs/fraud/prevention/avs-cvv/#cvv-best-practices) - Always require on first purchase

**Tuning existing rules?**

1.  [Run shadow mode test](https://paymentsandrisk.com/docs/fraud/prevention/avs-cvv/#finding-your-avs-thresholds) - 2 weeks minimum
2.  [Review international strategy](https://paymentsandrisk.com/docs/fraud/prevention/avs-cvv/#international-avs-strategy) - Different rules needed
3.  [Combine signals](https://paymentsandrisk.com/docs/fraud/prevention/avs-cvv/#combining-avs-and-cvv) - AVS + CVV decision matrix

**Fighting chargebacks with AVS/CVV?**

1.  [Check compelling evidence requirements](https://paymentsandrisk.com/docs/chargebacks/representment/compelling-evidence/) - AVS/CVV for representment
2.  [Review impact on disputes](https://paymentsandrisk.com/docs/fraud/prevention/avs-cvv/#impact-on-chargebacks) - What wins cases
3.  [Layer with 3DS](https://paymentsandrisk.com/docs/fraud/prevention/3ds/) - For liability shift

* * *

## See Also

-   [3D Secure](https://paymentsandrisk.com/docs/fraud/prevention/3ds/) - Liability shift authentication
-   [Risk Scoring](https://paymentsandrisk.com/docs/fraud/prevention/risk-scoring/) - Combining fraud signals
-   [Device Fingerprinting](https://paymentsandrisk.com/docs/fraud/detection/device-fingerprinting/) - Device intelligence
-   [Compelling Evidence](https://paymentsandrisk.com/docs/chargebacks/representment/compelling-evidence/) - Fighting chargebacks
-   [Third-Party Fraud](https://paymentsandrisk.com/docs/fraud/types/third-party/) - Stolen card fraud
-   [Decline Codes](https://paymentsandrisk.com/docs/reference/decline-codes/) - Understanding declines
-   [Representment](https://paymentsandrisk.com/docs/chargebacks/representment/) - Fighting disputes
-   [Velocity Rules](https://paymentsandrisk.com/docs/fraud/detection/velocity-rules/) - Pattern detection
-   [Authorization Basics](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/) - Auth flow
-   [Going Global](https://paymentsandrisk.com/docs/payments/going-global/) - International AVS challenges
-   [Processor Rules Configuration](https://paymentsandrisk.com/docs/fraud/processor-rules-configuration/) - Setting up rules
-   [Checkout Conversion](https://paymentsandrisk.com/docs/payments/checkout-conversion/) - Friction balance