# EMV Tags Specifications for Card Present

In a **Card Present (CP)** environment, transaction security is anchored in the exchange of **Tag Length Value (TLV)** data between the card's chip and the Getnet gateway. This page provides a technical reference for the specific EMV tags typically bundled within the `emv` payload of the **Regional API**.

## The Anatomy of a Tag (TLV)

Every data element within the hardware-generated `emv` string follows the standard TLV format:

- **Tag:** A 1 or 2-byte hexadecimal identifier (`9F26`).
- **Length:** The size of the following value in bytes.
- **Value:** The actual data payload (a cryptogram or currency code).

## Core EMV Tags (Mandatory & Common)

Based on validated hardware payloads (such as the Chile/CLP integration), the following tags are critical for successful authorization.

| Tag | Name | Source | Description |
| --- | --- | --- | --- |
| **9F26** | **Application Cryptogram (ARQC)** | ICC | A unique 8-byte cryptogram generated by the card's chip and used by the issuer to verify the card's authenticity for each transaction. |
| **9F02** | **Amount, Authorized** | Terminal | The transaction amount in numeric format (in cents). |
| **9F34** | **CVM Results** | Terminal | Records the outcome of the Cardholder Verification Method negotiation (Online PIN verified, No CVM). Used by the gateway to confirm the verification method applied. |
| **95** | **Terminal Verification Results (TVR)** | Terminal | A 5-byte bitmap indicating which security checks were performed and their results (offline data authentication, PIN verification). |
| **9F33** | **Terminal Capabilities** | Terminal | Defines the terminal's supported capabilities for card data input, CVM, and security features. |
| **9F10** | **Issuer Application Data (IAD)** | ICC | Proprietary issuer data embedded in the card, used for risk management and cryptogram validation. |
| **9F36** | **Application Transaction Counter (ATC)** | ICC | A counter maintained by the card's chip that increments with every transaction, preventing replay attacks. |
| **9F37** | **Unpredictable Number** | Terminal | A 4-byte random number generated by the terminal for each transaction to ensure cryptogram uniqueness. |
| **5F2A** | **Transaction Currency Code** | Terminal | The ISO 4217 numeric currency code (`0032` for CLP, `0986` for BRL). |
| **5F34** | **PAN Sequence Number (PSN)** | ICC | Differentiates between multiple cards issued to the same account sharing the same Primary Account Number (PAN). |
| **9A** | **Transaction Date** | Terminal | The date the transaction was initiated, in YYMMDD format. |
| **9C** | **Transaction Type** | Terminal | Indicates the type of financial transaction (`00` for Purchase). |
| **9F1A** | **Terminal Country Code** | Terminal | The ISO 3166-1 numeric country code of the terminal's location (`0152` for Chile). |

## Detailed Payload Validation

To ensure your implementation is robust, your hardware must concatenate these tags into a single hexadecimal string for the `data.payment.card.emv` field.

<Callout type="warning">

The `emv` field must contain all tags as a single, unspaced hex-encoded string. Do not include spaces or separators between TLV elements.

</Callout>

### Example Decoded String

Here is a breakdown of how the gateway reads a validated chip payload extracted from a real transaction:

> **`9F26 08 819BA36F3F793414`**
> - **Tag:** `9F26` (Application Cryptogram)
> - **Length:** `08` (8 bytes)
> - **Value:** `819BA36F3F793414` (The ARQC)

The full `emv` string in the API request would look like this (all tags concatenated without spaces):

```
9f2701809f3303e0f8c8950580000080009f37045d21705a9f100706010a03a0b8089f2608819ba36f3f7934149f360205b782021c009c01009f1a0204849a032002279f02060000000309605F2A0200325f3401019f34031e0300
```

## Security Best Practices

- **Do Not Hardcode Tag Lists:** Tag requirements can evolve based on regional regulations or card scheme updates. Your parser should be flexible enough to handle unexpected tags without failing.
- **Hexadecimal Encoding:** Ensure all TLV data is correctly converted to a hex-encoded string before submission to the API.
- **Sensitive Data Handling:** While tags like `5A` (PAN) or `57` (Track 2 Equivalent Data) exist in the EMV standard, they are typically sent in dedicated API fields (`card.number`, `card.track_2`) rather than within the generic `emv` string to maintain PCI DSS compliance.
- **ARQC Validation:** The Application Cryptogram (`9F26`) is the most critical tag. An invalid or missing ARQC will result in a declined transaction.

## Read More

- **PIN Validation**: Technical requirements for `pin_block` and `ksn` transmission.
- **Card Entry Modes**: How to switch between `chip`, `chip_contactless`, and `magnetic_stripe`.
- **EMV Technology Overview**: Deep dive into TLV tags and chip cryptograms.
- **Single-Step Payments**: Step-by-step guide to your first physical sale.