# Introduction to Card Present

A **Card Present (CP)** transaction occurs when a payment is initiated via physical hardware (such as a POS terminal, mPOS, or an integrated PIN pad) where the card is physically read by the device.

Unlike Ecommerce (Card-Not-Present), where a user manually types card details into a browser, CP transactions rely on the exchange of encrypted, hardware-generated data. In the context of the **Regional API**, this means moving away from raw card numbers and toward secure **EMV (Chip)** and **Magnetic Stripe** payloads using **DUKPT (Derived Unique Key Per Transaction)** encryption.

## The Four Pillars of Card Present

To understand how the Single Entry Point (SEP) handles physical sales, you must master these four fundamental concepts:

### 1. Terminal Identity

Every physical transaction must be tied to a specific piece of hardware registered within the Getnet ecosystem. This is handled by the **`terminal`** object, which requires the **`terminal_number`**, **`logical_code`**, and **`serial_number`**. These identifiers tell the gateway exactly which physical device is requesting authorization, which is critical for security, regional tax reporting, and terminal-specific reconciliation.

### 2. Secure Entry Modes

The `entry_mode` field identifies how the card data was captured, which determines the subsequent data requirements in the `card` object:

- **`chip`**: The card was inserted into an Integrated Circuit Card (ICC) reader.
- **`magnetic_stripe`**: The card was swiped, requiring full `track_2` data.
- **`chip_contactless`**: The card or mobile wallet was tapped via Near Field Communication (NFC).

### 3. Cardholder Verification Methods (CVM)

Verification is no longer just a "CVV check." In Card Present flows, the **`cardholder_verification_method`** defines the security handshake:

- **`online_pin`**: Requires the encrypted **`pin_block`** and **`ksn`** (Key Serial Number) from the hardware.
- **`no_cvm`**: Used for low-value or contactless transactions where no PIN is required.

### 4. The Encrypted Payload

Instead of sending sensitive card data in plain text, your hardware reader generates secure strings:

- **`emv`**: A collection of **Tag-Length-Value (TLV)** tags captured from the chip.
- **`track_1`** and **`track_2`**: The digital equivalent of the magnetic stripe, often required even in chip transactions for compatibility.

## Network Topologies: How Data Reaches the API

The Regional API supports two primary ways for your hardware to communicate:

- **Direct Integration**: The terminal connects directly to Getnet's cloud endpoints.
- **Merchant Host**: The terminal sends data to your internal server (Host), which then forwards the request to the Regional API.

## Why Card Present?

The primary driver for hardware integration is the **Liability Shift**. When you process a transaction using **EMV (Chip & PIN)** technology, the responsibility for fraudulent transactions shifts from the merchant to the card issuer. Because the physical chip and encrypted PIN are nearly impossible to clone, the gateway treats these transactions with the highest level of trust.