Getnet DocsGetnet Docs

Card Entry Modes

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 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 FieldAuthentication MethodVerification Methods
chipemv (TLV)Dynamic EMVonline_pin, no_cvm, signature
chip_contactlessemv (TLV)Dynamic EMV / NFCno_cvm, online_pin
magnetic_stripetrack_2Static TrackNone (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