# 

AVS and CVV are the two fraud signals a card-not-present transaction gets for
free. Both run during authorization, and both report back on the response.

**Neither one declines a transaction on its own.** An issuer can approve a payment
whose address did not match at all. Deciding what to do with a mismatch is your
call, not ours.

## How to request them

Both are driven by what you send in `payment_method`:

| Check | Send |
|  --- | --- |
| AVS | `billing_address`, especially `line1` and `postal_code` |
| CVV | `cvv` |


Omit them and the checks do not run. You lose the signal and, for AVS, usually
pay a higher interchange rate — see
[Card networks and interchange](/docs/concepts/card-networks-and-interchange).

## AVS result codes

`payment_method.avs_result_code` on the response.

| Code | Meaning |
|  --- | --- |
| `Y` | Street address and postal code both matched |
| `X` | Street address and full US ZIP+4 both matched |
| `A` | Street address matched, postal code did not |
| `Z` | Postal code matched, street address did not |
| `W` | US ZIP+4 matched, street address did not |
| `N` | Neither matched |
| `U` | Address information unavailable |
| `R` | Retry — AVS was unavailable or timed out |
| `S` | AVS not supported by the issuer |
| `P` | AVS not applicable to this transaction |
| `B` | No address supplied, or the transaction was declined |
| `0` | AVS not requested or not applicable. An **integer**, not a string |


`avs_response` carries the same thing in words.

Note that `0` is an integer while every other value is a string. A strictly typed
client needs to accept both.

## CVV results

`payment_method.cvv_result_code` is a single character, most often `M` for a
match. It is not a closed enum in the API description — the processor's own value
passes through, so treat an unfamiliar character as "no useful signal" rather
than as a failure.

It is null on void and refund responses, where CVV is not re-checked.

**Never store a CVV.** Not encrypted, not hashed, not briefly. It is prohibited
after authorization, and it is the single most common PCI finding.

## Deciding what to do

A reasonable default for card-not-present:

| Result | Common handling |
|  --- | --- |
| AVS `Y` or `X`, CVV match | Accept |
| AVS `Z` or `A`, CVV match | Accept. Partial address mismatches are common and often innocent — a customer who moved, or a formatting difference |
| AVS `N`, CVV match | Review, especially above a value threshold |
| CVV mismatch | Treat as a strong signal regardless of AVS |
| AVS `U`, `R`, `S` or `P` | No signal. Decide on other grounds |


Tune the thresholds to your own fraud experience. Being strict costs you real
customers; being loose costs you chargebacks.

## Next steps

* [Accept a card payment](/docs/payments/accept-a-card-payment)
* [Handle declines](/docs/payments/handle-declines)
* [Test cards and test accounts](/docs/reference/test-cards)