# EMV Technology in SEP Card Present

**EMV** (Europay, Mastercard, and Visa) is the global standard for secure credit and debit card payments based on Integrated Circuit Card (ICC) technology. Within the **Single Entry Point (SEP)** ecosystem, the Regional API processes these transactions by consuming hardware-encrypted data strings captured during the physical interaction between the card and the reader.

Integrating EMV technology ensures **Liability Shift** protection, transferring the risk of fraud-related chargebacks from the merchant to the card issuer.

## The Core of EMV: TLV Data

Unlike e-commerce transactions that utilize clear-text card numbers, EMV transactions communicate via the **TLV (Tag-Length-Value)** format. This encoding ensures that sensitive card data and transaction cryptograms are transmitted securely.

- **Tag**: A hexadecimal identifier for a specific data element (e.g., `9F02` for Amount, Authorized).
- **Length**: Indicates the size of the value in bytes.
- **Value**: The actual encrypted or encoded information (the payload).

In the Regional API, this entire collection of tags is passed as a single concatenated hexadecimal string in the **`emv`** field within the `card` object.

## Implementation in the Regional API

To process an EMV transaction, developers must map hardware-captured data to the `POST /v2/payments` request. The gateway uses the following fields to trigger EMV processing logic:

| Field | Requirement | Technical Purpose |
| --- | --- | --- |
| **`payment_method`** | Mandatory | Must use "Direct" enums (`DIRECT_CREDIT`). |
| **`emv`** | Mandatory | The full TLV string collected from the card's chip. |
| **`entry_mode`** | Mandatory | Must be set to `chip` (contact) or `chip_contactless` (NFC). |
| **`aid`** | Mandatory | The Application Identifier (e.g., `A0000000031010` for Visa). |

## Cardholder Verification Methods (CVM)

The **`cardholder_verification_method`** field defines how the customer’s identity is confirmed during the transaction:

* **`online_pin`**: The PIN is encrypted by the hardware and sent to the issuer for real-time validation.
* **`offline_pin`**: The PIN is validated locally by the card's chip.
* **`signature`**: The customer provides a physical or digital signature.
* **`no_cvm`**: Verification is bypassed (common in low-value contactless payments).

## Security and Online PIN Validation

For transactions requiring **Online PIN**, the API utilizes the **DUKPT** (Derived Unique Key Per Transaction) management system to ensure PCI compliance.

### Mandatory PIN Objects

When `cardholder_verification_method` is set to `online_pin`, the following fields become mandatory:

1. **`pin_block`**: An ISO-9564 formatted encrypted PIN payload.
2. **`ksn` (Key Serial Number)**: A 20-digit hexadecimal string used by the gateway to identify the decryption key.

### Service Code Context

The API also evaluates specialized flags to confirm the physical nature of the card:

* **`chip`**: Set to `true` to confirm the presence of a physical chip.
* **`pin_required`**: Informs the gateway if a PIN was mandatory for that specific card.

## Read More

To continue your integration, explore these related technical guides:

- **[Card Present Overview](/en/global-api/sep-card-present/card-present-integration)**: Understand the unified SEP architecture and regional availability.
- **[Card Entry Modes](/en/global-api/sep-card-present/core-concepts-cp/card-entry-modes-cp)**: Detailed breakdown of `chip`, `chip_contactless`, and `magnetic_stripe` payloads.
- **[Single-Step Payments](/en/global-api/sep-card-present/payment-guides-cp/single-step-payment-cp)**: Learn how to perform immediate sale-and-capture transactions.
- **[Pre-authorized Payments](/en/global-api/sep-card-present/payment-guides-cp/pre-auth-payment-cp)**: Implement the two-step flow for reservations and delayed captures.