# 

## Fraud prevention layers

Effective fraud prevention combines multiple verification methods. My Paradise Pay integrates several checks that run automatically during transaction authorization.

![image](https://files.modern-mermaid.live/images/1776270755946-mermaid-diagram-1776270756131.png)

## Address Verification Service (AVS)

AVS compares the billing address provided in the transaction with the address on file at the card-issuing bank. The check happens automatically when you include `address_line1` and `zip` in the payment method.

### How to send AVS data

Include the address fields in the `payment_method` object.

```json
{
  "type": "sale",
  "amount": 1999,
  "payment_method": {
    "type": "card",
    "pan": "4111111111111234",
    "expiry": {
      "month": "03",
      "year": "2028"
    },
    "cardholder_name": "John Doe",
    "cvv": "456",
    "address_line1": "123 Main St",
    "zip": "62704",
    "cvv": "456"
  },
  "metadata": {},
  "recurring": false,
  "purchase_description": "Dog food"
}
```

### AVS result codes

The `avs_result_code` field in the transaction response indicates the match result.

| Code | Description | Risk level |
|  --- | --- | --- |
| `y` | Street address and postal code both match | Low |
| `x` | Street address and ZIP+4 both match | Low |
| `a` | Street address matches, postal code does not | Medium |
| `z` | Postal code matches, street address does not | Medium |
| `w` | ZIP+4 matches, street address does not | Medium |
| `n` | Neither street address nor postal code matches | High |
| `b` | No address information provided or transaction declined | Review required |
| `r` | AVS unavailable or timed out — retry | Retry |
| `s` | AVS not supported by card issuer | Not applicable |
| `u` | Address information unavailable | Not applicable |
| `p` | AVS not applicable for this transaction | Not applicable |


### Interpreting AVS results

My Paradise Pay returns the AVS result but does not automatically decline transactions based on AVS mismatch. It is your responsibility to decide how to handle each result.

**Recommended approach:**

* **`y` or `x`** — proceed with the transaction.
* **`a` or `z` or `w`** — partial match; proceed with caution or request the person to verify their address.
* **`n`** — no match; consider declining or flagging for manual review.
* **`r`** — retry the transaction.
* **`s`, `u`, `p`** — AVS not available; rely on other fraud signals.


AVS is advisory
AVS results are informational. The processor may still approve a transaction with an AVS mismatch. Implement your own business logic to decide whether to fulfill orders based on AVS results.

## CVV verification

The Card Verification Value (CVV / CVC / CID) is the 3- or 4-digit code printed on the physical card. Including the CVV in a transaction proves the person has possession of the card, reducing the risk of fraud from stolen card numbers.

### How to send CVV

Include the `cvv` field in the `payment_method` object.

```json
"payment_method": {
  "type": "card",
  "pan": "4111111111111234",
  "expiry": {
    "month": "03",
    "year": "2028"
  },
  "cardholder_name": "John Doe",
  "cvv": "456"
},
```

### CVV result codes

The `cvv_result` field in the response indicates whether the CVV matched.

#### Visa

| Code | Description |
|  --- | --- |
| `M` | CVV match |
| `N` | CVV no match |
| `P` | Not processed |
| `S` | Merchant indicated CVV not present on card |
| `U` | Issuer not certified / no encryption keys |


#### Mastercard

| Code | Description |
|  --- | --- |
| `0` | Authentication failed |
| `1` | Authentication attempted — liability shift applies |
| `2` | Authentication successful — full protection |


#### American Express

| Code | Description |
|  --- | --- |
| `1` | AEVV failed — authentication, issuer key |
| `2` | AEVV passed — authentication, issuer key |
| `3` | AEVV passed — attempt, issuer key |
| `4` | AEVV failed — attempt, issuer key |
| `7` | AEVV failed — attempt, issuer not participating, network key |
| `8` | AEVV passed — attempt, issuer not participating, network key |
| `9` | AEVV failed — attempt, ACS not available, network key |
| `A` | AEVV passed — attempt, ACS not available, network key |
| `U` | AEVV unchecked |


### Interpreting CVV results

* **Match (`M` for Visa, `2` for Mastercard)** — proceed normally.
* **No match (`N` for Visa, `0` for Mastercard)** — high fraud risk; consider declining.
* **Not processed / unavailable** — rely on other fraud signals.


CVV is never stored
PCI-DSS prohibits storing CVV after authorization. My Paradise Pay discards the CVV immediately after the authorization check. For tokenized (stored) transactions, CVV is not required or available.

## Address check on tokenized cards

When you create a payment token with address data, My Paradise Pay verifies the address with the card issuer and returns `address_check` results.

```json
{
  "payment_token": "PAYMENT_TOKEN-01KFDKXMQ637EKEAY410MSQSXB",
  "address_check": {
    "address_line1_match": "match",
    "address_zip_match": "match"
  },
  "brand": "visa",
  "last_four": "1234"
}
```

This lets you verify the person's address at tokenization time, before any transaction is processed.

## Combining fraud signals

No single check is sufficient on its own. Use multiple signals together for effective fraud prevention.

![image](https://files.modern-mermaid.live/images/1776270828244-mermaid-diagram-1776270828411.png)

### Recommended fraud decision matrix

| CVV result | AVS result | Suggested action |
|  --- | --- | --- |
| Match | Full match (`y`, `x`) | Fulfill order |
| Match | Partial match (`a`, `z`, `w`) | Fulfill low-value; review high-value |
| Match | No match (`n`) | Flag for review or decline |
| No match | Any | Decline |
| Unavailable | Full match | Fulfill with monitoring |
| Unavailable | No match | Decline or hold for review |


## Additional fraud prevention measures

Beyond AVS and CVV, consider implementing these application-level controls.

### Velocity checks

Monitor transaction frequency to detect automated fraud attempts.

| Check | Example threshold | Action |
|  --- | --- | --- |
| Transactions per card per hour | > 5 | Block and alert |
| Declined transactions per IP | > 3 in 10 minutes | Temporary IP block |
| Total amount per card per day | > 5,000.00 USD | Require additional verification |


### Order-level signals

* **Shipping vs. billing address mismatch** — higher fraud risk for card-not-present transactions.
* **Email domain** — free email providers correlate with higher fraud rates.
* **Device fingerprinting** — repeated attempts from the same device with different cards.
* **Geolocation** — IP location differs significantly from billing address.


### 3D Secure (3DS)

3D Secure adds an issuer-controlled authentication step (for example, Visa Secure, Mastercard Identity Check). When the cardholder successfully authenticates, liability for fraudulent chargebacks shifts from the merchant to the issuing bank.

## Further reading

* [About PCI-DSS compliance](/docs/concepts/security-compliance/pci-dss-overview)
* [About data protection](/docs/concepts/security-compliance/data-protection)
* [About error handling](/docs/concepts/api-fundamentals/error-handling)
* [Integration best practices](/docs/get-started/integration-best-practices)