# Card Entry Modes

In a **Card Present** integration, the `entry_mode` field is the primary "switch" that tells the Getnet gateway how to process the incoming payment data. Selecting the correct entry mode is critical for transaction authorization, as it dictates whether the API expects an **EMV (Chip)** payload, **Track 2** data, or specific **PIN** encryption fields.

## Supported Entry Modes

The Regional API supports three primary physical entry methods, each with distinct security and data requirements.

### Chip (Contact EMV)

The card is physically inserted into the reader’s chip slot.

* **Technical Payload**: Requires the **`emv`** data (TLV tags) generated by the chip.
* **Security**: Provides the highest level of protection through dynamic cryptograms and supports **Liability Shift**.
* **Verification**: Commonly used with `online_pin` (requiring `pin_block` and `ksn`) or `signature`.

### Chip Contactless (NFC)

The card or mobile wallet (Apple Pay, Google Pay) is tapped against an NFC enabled reader.

* **Technical Payload**: Transmits an EMV payload similar to the contact chip interface, but optimized for contactless transactions (NFC).
* **Verification**: Supports `no_cvm` and `online_pin`. Low-value taps and mobile wallets that use on-device biometrics (CDCVM) typically use `no_cvm`. Higher-value taps may require `online_pin`.

### Magnetic Stripe (Swipe)

The card is swiped through the reader's magnetic head.

* **Technical Payload**: Requires the **`track_2`** data.
* **Security**: Uses static data and does not support EMV dynamic cryptograms. Use this mode only as a legacy fallback or where chip technology is unavailable.
* **Verification**: Magnetic stripe transactions don't use any CVM. Omit the `cardholder_verification_method` field from the request.

## Technical Comparison Table

| Entry Mode (`entry_mode`) | Primary Data Field | Authentication Method | Verification Methods                |
| ------------------------- | ------------------ | --------------------- | ----------------------------------- |
| **`chip`**                | `emv` (TLV)        | Dynamic EMV           | `online_pin`, `no_cvm`, `signature` |
| **`chip_contactless`**    | `emv` (TLV)        | Dynamic EMV / NFC     | `no_cvm`, `online_pin`              |
| **`magnetic_stripe`**     | `track_2`          | Static Track          | None (omit the field)               |

## Technical Nuance: EMV Fallback

An **EMV Fallback** occurs when a terminal with an active chip reader attempts to read a chip card, but the chip is unreadable due to damage or technical failure.

* **Process**: The terminal prompts the user to "Swipe" the card instead.
* **API Implementation**: In this scenario, you must send `entry_mode: magnetic_stripe` but include the specific **Fallback Indicator** (if required by regional regulations) to inform the issuer that a chip was present but could not be utilized.
* **Risk Note**: Fallback transactions typically carry a higher risk and may void **Liability Shift** protection.

## Security Requirements by Mode

* **PIN-Pad Usage**: If the entry mode is `chip` and the method is `online_pin`, the `pin_block` and `ksn` must be transmitted via **DUKPT** encryption.
* **Field Exclusion**: When you use `magnetic_stripe`, omit the `emv` and `cardholder_verification_method` fields from the request to avoid validation errors.

## Read More

* [Card Present Overview](/en/global-api/sep-card-present/card-present-integration): Introduction to the SEP hardware ecosystem.
* [EMV Technology Guide](/en/global-api/sep-card-present/core-concepts-cp/emv-technology): Deep dive into TLV tags and chip logic.
* [Single-Step Payments](/en/global-api/sep-card-present/payment-guides-cp/single-step-payment-cp): How to implement a direct sale using these entry modes.