Getnet DocsGetnet Docs

Cardholder Verification Methods (CVM)

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 the Card Present (CP) ecosystem, the Cardholder Verification Method (CVM) is the critical handshake used to confirm that the person presenting the card is the legitimate owner. Unlike the simple CVV check used in e-commerce, CVMs in the physical world utilize a hierarchy of security protocols from physical signatures to sophisticated encrypted PINs to mitigate the risk of fraud.

The Role of CVM in Hardware Integration

When you initiate a transaction via the Regional API, the cardholder_verification_method field informs the Getnet gateway which verification process was performed by the hardware terminal. The verification method used is determined by the intersection of the card’s internal priority list and the terminal’s capabilities.

Successfully executing a high security CVM is what triggers the Liability Shift, protecting the merchant from fraudulent chargeback claims.

Supported Verification Methods

The Regional API supports the following CVM enums, which must be mapped correctly in your card object:

online_pin

The most secure method for real time verification. The customer enters their PIN on the terminal’s secure PIN pad.

  • Technical Requirement: Requires the transmission of an encrypted pin_block and a ksn (Key Serial Number).
  • Encryption: Utilizes the DUKPT (Derived Unique Key Per Transaction) management scheme to ensure end to end security.

offline_pin

The PIN is validated locally by the card’s chip without communicating with the issuer.

  • Technical Requirement: The terminal handles the verification locally. In the API request, you simply set the CVM to offline_pin.
  • Use Case: Ideal for environments with intermittent connectivity where the card supports local verification.

signature

A legacy verification method where the customer provides a physical signature on a paper receipt or a digital signature on the terminal screen.

  • Technical Requirement: The merchant is responsible for storing the signature for potential chargeback disputes.
  • Implementation: Used primarily with chip when the card does not support a PIN or the terminal lacks a PIN pad.

no_cvm

Verification is bypassed entirely.

  • Common Use Cases: Low value contactless (NFC) taps or “Quick Payment” environments like transit turnstiles.
  • Risk Note: These transactions often have lower limits and may not carry the same level of fraud protection as PIN verified sales.

Technical Mapping Table

CVM Enum (cardholder_verification_method)Required Security FieldsBest Entry Mode
online_pinpin_block, ksnchip, chip_contactless
offline_pinNone (Gateway side)chip
signatureNonechip
no_cvmNonechip_contactless
(Omitted)None. Magnetic stripe transactions don’t use a CVM.magnetic_stripe

CVM Selection Logic (The Hierarchy)

During a transaction, the terminal and the card “negotiate” the best possible verification method based on a set of rules:

  1. Card Capability: The chip contains a list of CVMs it supports in order of preference (Online PIN, Signature, No CVM).
  2. Terminal Capability: The hardware reports what it can do (“I have a PIN pad and a screen”).
  3. The Result: The terminal selects the highest priority CVM that both the card and the hardware support.

Technical Deep Dive: The outcome of this negotiation is recorded in EMV Tag 9F34 (CVM Results). The terminal uses this tag to populate the correct enum in the API request.

Read More

  • PIN Validation: Deep dive into DUKPT, ISO-0 formats, and PIN block construction.
  • Card Entry Modes: Understand how entry modes like chip and magnetic_stripe influence CVM availability.
  • Quick Start Guide: Execute your first online_pin transaction in Sandbox.