Getnet DocsGetnet Docs

EMV Tags Specifications for 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

In a Card Present (CP) environment, transaction security is anchored in the exchange of Tag Length Value (TLV) data between the card’s chip and the Getnet gateway. This page provides a technical reference for the specific EMV tags typically bundled within the emv payload of the Regional API.

The Anatomy of a Tag (TLV)

Every data element within the hardware-generated emv string follows the standard TLV format:

  • Tag: A 1 or 2-byte hexadecimal identifier (9F26).
  • Length: The size of the following value in bytes.
  • Value: The actual data payload (a cryptogram or currency code).

Core EMV Tags (Mandatory & Common)

Based on validated hardware payloads (such as the Chile/CLP integration), the following tags are critical for successful authorization.

TagNameSourceDescription
9F26Application Cryptogram (ARQC)ICCA unique 8-byte cryptogram generated by the card’s chip and used by the issuer to verify the card’s authenticity for each transaction.
9F02Amount, AuthorizedTerminalThe transaction amount in numeric format (in cents).
9F34CVM ResultsTerminalRecords the outcome of the Cardholder Verification Method negotiation (Online PIN verified, No CVM). Used by the gateway to confirm the verification method applied.
95Terminal Verification Results (TVR)TerminalA 5-byte bitmap indicating which security checks were performed and their results (offline data authentication, PIN verification).
9F33Terminal CapabilitiesTerminalDefines the terminal’s supported capabilities for card data input, CVM, and security features.
9F10Issuer Application Data (IAD)ICCProprietary issuer data embedded in the card, used for risk management and cryptogram validation.
9F36Application Transaction Counter (ATC)ICCA counter maintained by the card’s chip that increments with every transaction, preventing replay attacks.
9F37Unpredictable NumberTerminalA 4-byte random number generated by the terminal for each transaction to ensure cryptogram uniqueness.
5F2ATransaction Currency CodeTerminalThe ISO 4217 numeric currency code (0032 for CLP, 0986 for BRL).
5F34PAN Sequence Number (PSN)ICCDifferentiates between multiple cards issued to the same account sharing the same Primary Account Number (PAN).
9ATransaction DateTerminalThe date the transaction was initiated, in YYMMDD format.
9CTransaction TypeTerminalIndicates the type of financial transaction (00 for Purchase).
9F1ATerminal Country CodeTerminalThe ISO 3166-1 numeric country code of the terminal’s location (0152 for Chile).

Detailed Payload Validation

To ensure your implementation is robust, your hardware must concatenate these tags into a single hexadecimal string for the data.payment.card.emv field.

The emv field must contain all tags as a single, unspaced hex-encoded string. Do not include spaces or separators between TLV elements.

Example Decoded String

Here is a breakdown of how the gateway reads a validated chip payload extracted from a real transaction:

9F26 08 819BA36F3F793414

  • Tag: 9F26 (Application Cryptogram)
  • Length: 08 (8 bytes)
  • Value: 819BA36F3F793414 (The ARQC)

The full emv string in the API request would look like this (all tags concatenated without spaces):

9f2701809f3303e0f8c8950580000080009f37045d21705a9f100706010a03a0b8089f2608819ba36f3f7934149f360205b782021c009c01009f1a0204849a032002279f02060000000309605F2A0200325f3401019f34031e0300

Security Best Practices

  • Do Not Hardcode Tag Lists: Tag requirements can evolve based on regional regulations or card scheme updates. Your parser should be flexible enough to handle unexpected tags without failing.
  • Hexadecimal Encoding: Ensure all TLV data is correctly converted to a hex-encoded string before submission to the API.
  • Sensitive Data Handling: While tags like 5A (PAN) or 57 (Track 2 Equivalent Data) exist in the EMV standard, they are typically sent in dedicated API fields (card.number, card.track_2) rather than within the generic emv string to maintain PCI DSS compliance.
  • ARQC Validation: The Application Cryptogram (9F26) is the most critical tag. An invalid or missing ARQC will result in a declined transaction.

Read More

  • PIN Validation: Technical requirements for pin_block and ksn transmission.
  • Card Entry Modes: How to switch between chip, chip_contactless, and magnetic_stripe.
  • EMV Technology Overview: Deep dive into TLV tags and chip cryptograms.
  • Single-Step Payments: Step-by-step guide to your first physical sale.