Getnet DocsGetnet Docs

Introduction to Card Present

View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this pageOpen in PerplexityAsk questions about this page
Connect to CursorUse these docs in CursorConnect to VS CodeUse these docs in VS Code

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.