---
description: >-
  Understand AVS and CVC verification results to assess fraud risk on card
  payments.
---

# Handling AVS / CVC

Address Verification System (AVS) and Card Verification Code (CVC/CVV) checks are fraud prevention tools that compare customer-provided data against the card issuer's records.

## How It Works

When you include the `sender.address` (billing address) in your payment request, the Inyo Gateway forwards it to the card network for verification. The results are returned in the payment response.

> **Note:** AVS and CVC results do **not** directly control whether a payment is approved or declined. The issuing bank may authorize a payment even with mismatched AVS/CVC. These results are advisory — use them as signals in your own fraud decision logic.

## Response Fields

Every payment response includes these verification fields:

```json
{
  "cvcResult": "APPROVED",
  "avsResult": "APPROVED",
  "avsCardholderNameResult": "N/A",
  "avsTelephoneResult": "N/A"
}
```

## CVC Verification (`cvcResult`)

CVC verifies the 3 or 4 digit security code on the card.

| Status | Meaning | Action |
|---|---|---|
| `APPROVED` | CVV matches issuer records | ✅ Low fraud risk |
| `FAILED` | CVV does not match | ⚠️ High fraud risk — consider voiding even if authorized |
| `NOT_SENT` | CVV was not provided in the request | ℹ️ No verification performed |
| `N/A` | Not applicable (e.g., during 3DS challenge) | ℹ️ Check after challenge completes |

## AVS Verification (`avsResult`)

AVS compares the billing address (house number, street, and postal code) against the issuer's records.

| Status | Meaning | Action |
|---|---|---|
| `APPROVED` | Address components match | ✅ Low fraud risk |
| `FAILED` | Address components don't match | ⚠️ Elevated fraud risk |
| `NOT_SENT` | No billing address was provided | ℹ️ No verification performed |
| `N/A` | Not applicable (e.g., 3DS challenge pending) | ℹ️ Check after authorization |

## Configuration Options

During merchant onboarding, you can configure AVS behavior at the Inyo level:

1. **Inyo-managed** — Inyo automatically evaluates AVS results and may decline or reverse transactions that fail verification, based on rules you define together.
2. **Self-managed** — Inyo returns the raw AVS/CVC results and your system decides how to handle them (e.g., void transactions with failed CVC).

Contact the Inyo team to configure your preferred approach.

## Best Practices

1. **Always send billing address** — Even if AVS is advisory, providing address data improves authorization rates and gives you fraud signals.

2. **Combine signals** — Don't rely on a single check. Evaluate CVC + AVS + 3DS results together with transaction context (amount, velocity, device fingerprint).

3. **Void suspicious authorizations** — If a payment is authorized but CVC = `FAILED`, consider [voiding](../void.md) it before capture rather than accepting the risk.

4. **Log results** — Store AVS/CVC results for chargeback disputes. Demonstrating you verified the cardholder's identity strengthens your case.

## Testing AVS / CVC

Use special values in sandbox to simulate different verification outcomes. See [Test Data — Cards](../../../../test-data/cards.md) for the full table.

**CVC test values (Visa/MC/Discover):**

| CVV Value | Result |
|---|---|
| `555` | Matched (APPROVED) |
| `444` | Not matched (FAILED) |
| _(empty)_ | Not supplied |

**AVS test values (via zip code):**

| Zip Code | Result |
|---|---|
| `AAAAA` | Full match (APPROVED) |
| `JJJJJ` | No match (FAILED) |
| _(empty)_ | Not supplied |