AVS & CVV
Before configuring AVS/CVV rules, understand:
- Authorization basics and the payment flow
- Risk scoring concepts (AVS/CVV feed into scores)
- Your current fraud rate and fraud metrics baseline
- 3DS for liability shift (AVS/CVV don't shift liability)
- AVS: Checks billing address vs. issuer records—Y=full match (accept), N=no match (review/decline), U/G=unavailable (use other signals)
- CVV: Verifies card code—M=match (accept), N=no match (decline); proves physical card possession
- Neither shifts liability—for liability shift, use 3D Secure
- Don't hard-decline AVS mismatches blindly: 20-30% of legitimate customers fail AVS (formatting, moves, issuer quirks)
- Test first: Shadow mode 2 weeks, enforce only if over 30% of flagged transactions were fraud
AVS checks if billing address matches what the issuer has. CVV verifies the 3-4 digit code on the physical card.
Neither is foolproof. Neither shifts liability. Both help you make better authorization decisions about which transactions to accept. For liability shift, see 3D Secure.
Legitimate customers fail AVS surprisingly often (20-30% for some merchants) due to formatting differences, recent moves, or issuer quirks. Being too strict kills good orders.
Before enforcing any AVS rule:
- Run in shadow mode for 2 weeks (flag but don't block)
- For every transaction you WOULD have declined, check: was it actually fraud?
- Calculate your false positive rate
Decision rule: Only enforce if more than 30% of flagged transactions were fraud AND fewer than 1% of total transactions would be blocked.
Address Verification Service (AVS)
How AVS Works
- Customer enters billing address at checkout
- Your processor sends address data to card network
- Issuer compares submitted address to their records
- AVS response code returned in the authorization response
- You decide: accept, decline, 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)
- International cards 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 | Frequency (International) |
|---|---|---|
| G | Global/international card | 40-60% of non-US |
| U | Unavailable | 20-30% |
| S | Service not supported | 10-20% |
| Y/A/Z | Actual match data | 10-30% (varies by country) |
International AVS Strategy
Don't: Decline all G/U responses (you'll reject 50%+ of international orders)
Do: Layer additional verification for international transactions
| Signal | Use For International |
|---|---|
| CVV | Always require (still works internationally) |
| 3DS | Strongly recommended (liability shift) |
| Email verification | Check for free/disposable emails (see identity verification) |
| Phone verification | Consider SMS verification for high-value |
| Shipping address analysis | Freight forwarders, PO boxes, known fraud addresses |
| Device fingerprint | 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
| 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 |
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:
- Pull last 30 days of transactions
- Apply proposed rule in shadow mode
- Calculate: What % would have been blocked? What % of those were actually fraud?
If the rule would block 2% of traffic but only 10% of those were fraud, you're blocking 1.8% of good customers. Probably too aggressive.
Decision rule: Only enforce if more than 30% of blocked transactions were fraud AND fewer than 0.5% of total traffic is blocked.
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
- Customer enters CVV at checkout
- Processor sends CVV to issuer
- Issuer verifies CVV matches card records
- 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
Proves physical possession: The CVV is printed on the card, not encoded on the magnetic stripe or stored in most databases. A fraudster with a stolen card number may not have the CVV. This helps prevent third-party fraud and card testing.
Required for compelling evidence: In chargeback disputes, CVV match strengthens your representment case.
Cannot be stored: PCI DSS prohibits storing CVV after authorization. Recurring transactions 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 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 |
Every threshold you set is a tradeoff: blocking more fraud vs. blocking more good customers.
Your optimal thresholds depend on:
- Your fraud rate (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 for how these signals combine.
Processor Configuration
Most payment gateways let you configure AVS/CVV rules:
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
- Selection bias: If you only look at declined transactions, you don't know how many good customers you blocked
- Lag time: Fraud shows up as chargebacks 30-90 days later. Your 2-week test might look clean but fail later.
- Fraudster adaptation: If you tighten AVS rules, sophisticated fraudsters will start using correct addresses. Measure total fraud, not just AVS-flagged fraud.
Impact on Chargebacks
For representment:
- AVS match is often required to fight fraud chargebacks
- CVV match strengthens your case against friendly fraud
- Without either, you may not qualify to represent under network rules
For Visa CE 3.0:
- Historical transactions with matching data help prove customer relationship
- AVS/CVV data from past orders supports compelling evidence
Next Steps
Just starting with AVS/CVV?
- Understand response codes - What each code means
- Test your thresholds - Backtest before enforcing
- Check CVV requirements - Always require on first purchase
Tuning existing rules?
- Run shadow mode test - 2 weeks minimum
- Review international strategy - Different rules needed
- Combine signals - AVS + CVV decision matrix
Fighting chargebacks with AVS/CVV?
- Check compelling evidence requirements - AVS/CVV for representment
- Review impact on disputes - What wins cases
- Layer with 3DS - For liability shift
See Also
- 3D Secure - Liability shift authentication
- Risk Scoring - Combining fraud signals
- Device Fingerprinting - Device intelligence
- Compelling Evidence - Fighting chargebacks
- Third-Party Fraud - Stolen card fraud
- Decline Codes - Understanding declines
- Representment - Fighting disputes
- Velocity Rules - Pattern detection
- Authorization Basics - Auth flow
- Going Global - International AVS challenges
- Processor Rules Configuration - Setting up rules
- Checkout Conversion - Friction balance