Getnet DocsGetnet Docs

EMV Technology in SEP 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

EMV (Europay, Mastercard, and Visa) is the global standard for secure credit and debit card payments based on Integrated Circuit Card (ICC) technology. Within the Single Entry Point (SEP) ecosystem, the Regional API processes these transactions by consuming hardware-encrypted data strings captured during the physical interaction between the card and the reader.

Integrating EMV technology ensures Liability Shift protection, transferring the risk of fraud-related chargebacks from the merchant to the card issuer.

The Core of EMV: TLV Data

Unlike e-commerce transactions that utilize clear-text card numbers, EMV transactions communicate via the TLV (Tag-Length-Value) format. This encoding ensures that sensitive card data and transaction cryptograms are transmitted securely.

  • Tag: A hexadecimal identifier for a specific data element (e.g., 9F02 for Amount, Authorized).
  • Length: Indicates the size of the value in bytes.
  • Value: The actual encrypted or encoded information (the payload).

In the Regional API, this entire collection of tags is passed as a single concatenated hexadecimal string in the emv field within the card object.

Implementation in the Regional API

To process an EMV transaction, developers must map hardware-captured data to the POST /v2/payments request. The gateway uses the following fields to trigger EMV processing logic:

FieldRequirementTechnical Purpose
payment_methodMandatoryMust use “Direct” enums (DIRECT_CREDIT).
emvMandatoryThe full TLV string collected from the card’s chip.
entry_modeMandatoryMust be set to chip (contact) or chip_contactless (NFC).
aidMandatoryThe Application Identifier (e.g., A0000000031010 for Visa).

Cardholder Verification Methods (CVM)

The cardholder_verification_method field defines how the customer’s identity is confirmed during the transaction:

  • online_pin: The PIN is encrypted by the hardware and sent to the issuer for real-time validation.
  • offline_pin: The PIN is validated locally by the card’s chip.
  • signature: The customer provides a physical or digital signature.
  • no_cvm: Verification is bypassed (common in low-value contactless payments).

Security and Online PIN Validation

For transactions requiring Online PIN, the API utilizes the DUKPT (Derived Unique Key Per Transaction) management system to ensure PCI compliance.

Mandatory PIN Objects

When cardholder_verification_method is set to online_pin, the following fields become mandatory:

  1. pin_block: An ISO-9564 formatted encrypted PIN payload.
  2. ksn (Key Serial Number): A 20-digit hexadecimal string used by the gateway to identify the decryption key.

Service Code Context

The API also evaluates specialized flags to confirm the physical nature of the card:

  • chip: Set to true to confirm the presence of a physical chip.
  • pin_required: Informs the gateway if a PIN was mandatory for that specific card.

Read More

To continue your integration, explore these related technical guides: