# Cardholder Verification Methods (CVM)

In the **Card Present (CP)** ecosystem, the **Cardholder Verification Method (CVM)** is the critical handshake used to confirm that the person presenting the card is the legitimate owner. Unlike the simple CVV check used in e-commerce, CVMs in the physical world utilize a hierarchy of security protocols from physical signatures to sophisticated encrypted PINs to mitigate the risk of fraud.

## The Role of CVM in Hardware Integration

When you initiate a transaction via the **Regional API**, the `cardholder_verification_method` field informs the Getnet gateway which verification process was performed by the hardware terminal. The verification method used is determined by the intersection of the card's internal priority list and the terminal's capabilities.

Successfully executing a high security CVM is what triggers the **Liability Shift**, protecting the merchant from fraudulent chargeback claims.

## Supported Verification Methods

The Regional API supports the following CVM enums, which must be mapped correctly in your `card` object:

### `online_pin`

The most secure method for real time verification. The customer enters their PIN on the terminal's secure PIN pad.

- **Technical Requirement**: Requires the transmission of an encrypted **`pin_block`** and a **`ksn`** (Key Serial Number).
- **Encryption**: Utilizes the **DUKPT** (Derived Unique Key Per Transaction) management scheme to ensure end to end security.

### `offline_pin`

The PIN is validated locally by the card's chip without communicating with the issuer.

- **Technical Requirement**: The terminal handles the verification locally. In the API request, you simply set the CVM to `offline_pin`.
- **Use Case**: Ideal for environments with intermittent connectivity where the card supports local verification.

### `signature`

A legacy verification method where the customer provides a physical signature on a paper receipt or a digital signature on the terminal screen.

- **Technical Requirement**: The merchant is responsible for storing the signature for potential chargeback disputes.
- **Implementation**: Used primarily with `chip` when the card does not support a PIN or the terminal lacks a PIN pad.

### `no_cvm`

Verification is bypassed entirely.

- **Common Use Cases**: Low value contactless (NFC) taps or "Quick Payment" environments like transit turnstiles.
- **Risk Note**: These transactions often have lower limits and may not carry the same level of fraud protection as PIN verified sales.

## Technical Mapping Table

| CVM Enum (`cardholder_verification_method`) | Required Security Fields | Best Entry Mode |
| --- | --- | --- |
| **`online_pin`** | `pin_block`, `ksn` | `chip`, `chip_contactless` |
| **`offline_pin`** | None (Gateway side) | `chip` |
| **`signature`** | None | `chip` |
| **`no_cvm`** | None | `chip_contactless` |
| **(Omitted)** | None. Magnetic stripe transactions don't use a CVM. | `magnetic_stripe` |

## CVM Selection Logic (The Hierarchy)

During a transaction, the terminal and the card "negotiate" the best possible verification method based on a set of rules:

1. **Card Capability**: The chip contains a list of CVMs it supports in order of preference (Online PIN, Signature, No CVM).
2. **Terminal Capability**: The hardware reports what it can do ("I have a PIN pad and a screen").
3. **The Result**: The terminal selects the highest priority CVM that both the card and the hardware support.

> **Technical Deep Dive**: The outcome of this negotiation is recorded in EMV Tag **9F34** (CVM Results). The terminal uses this tag to populate the correct enum in the API request.

## Read More

- **[PIN Validation](/en/global-api/sep-card-present/core-concepts-cp/pin-validation)**: Deep dive into DUKPT, ISO-0 formats, and PIN block construction.
- **[Card Entry Modes](/en/global-api/sep-card-present/core-concepts-cp/card-entry-modes-cp)**: Understand how entry modes like `chip` and `magnetic_stripe` influence CVM availability.
- **[Quick Start Guide](/en/global-api/sep-card-present/first-steps-cp/card-present-quickstart)**: Execute your first `online_pin` transaction in Sandbox.