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 e-commerce (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 utilizing 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 a unique terminal_number. This ID tells 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. Requires the emv TLV string and typically track_2.
  • 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). Requires the emv TLV string.

3. Cardholder Verification Methods (CVM)

In Card Present flows, the cardholder_verification_method field defines how the cardholder's identity was verified at the terminal:
  • online_pin: The customer entered a PIN on the terminal's secure PIN pad. Requires the encrypted pin_block and ksn (Key Serial Number) from the hardware.
  • offline_pin: The PIN was verified locally by the card's chip without transmitting it to the gateway. No additional fields are required.
  • signature: The cardholder signed a receipt or screen. No additional fields are required.
  • no_cvm: Used for low-value or contactless transactions where no PIN or signature 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, concatenated into a single hex-encoded string.
  • track_2: The digital equivalent of the magnetic stripe data, often required even in chip transactions for network 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, handling OAuth 2.0 authentication and JSON construction in its firmware.
  • Merchant Host: The terminal captures hardware data (EMV, Track 2, PIN Block) and sends it to your internal server, which then constructs and forwards the API request.

Why Card Present?

There are three primary business drivers for hardware integration:

  1. 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.
  2. PCI-DSS Scope Reduction: Because the hardware encrypts card data before it reaches your network, your servers never process raw card numbers. This significantly reduces your PCI-DSS compliance burden.
  3. Omnichannel Reconciliation: By using the same Regional API endpoints as your e-commerce integration, Card Present transactions appear in the same reporting and reconciliation flows, giving you a unified view of all sales.

Next Steps

On this page

Introduction to Card Present