Post 3: Contactless EMV Integration: Limits, CDCVM, Interface Switching and Refunds

Suggested slug: contactless-emv-limits-cdcvm-interface-switching-refunds

Meta description: Understand the separate roles of contactless transaction, CVM and floor limits—and troubleshoot CDCVM, use-contact outcomes and refund processing.

Contactless problems often begin when several independent controls are treated as one “contactless limit.” In practice, the reader evaluates different thresholds for different decisions.

The limits answer different questions

LimitDecision
Contactless transaction limitMay this amount use the contactless interface?
Reader CVM required limitIs cardholder verification required?
Reader contactless floor limitShould the transaction request online authorization?
Terminal floor limitGeneral terminal risk-management threshold; its use is kernel and configuration dependent

Boundary rules matter. One kernel or scheme profile may use >=, while another may use >. Never implement one shared comparison and assume it applies to every contactless kernel.

For Visa Kernel 3-style processing, a typical model is:

  • Amount at or above the contactless transaction limit: use another interface.
  • Amount at or above the CVM required limit: request a mutually supported CVM.
  • Amount at or above the reader contactless floor limit: request online authorization.

For Mastercard Kernel 2, the kernel consumes configuration data such as:

  • CVM Capability — CVM Required, tag DF8118
  • CVM Capability — No CVM Required, tag DF8119
  • Reader Contactless Floor Limit, tag DF8123

Treat the scheme kernel’s result as authoritative. An entry-point pre-processing result does not replace kernel-specific processing.

CDCVM and the “see phone” flow

Consumer Device Cardholder Verification Method (CDCVM) is performed on the consumer device—for example, with a passcode or biometric—rather than on the terminal.

For Visa-style processing, the terminal declares CDCVM support in the Terminal Transaction Qualifiers (TTQ, tag 9F66). A pre-tap flow can then occur:

  1. The consumer taps before completing device verification.
  2. The terminal tells the consumer to verify on the device.
  3. The original transaction is terminated or paused as required by the kernel outcome.
  4. The consumer verifies and presents the same device again.
  5. The transaction restarts without changing the amount.

For Mastercard Kernel 2, the kernel may return an outcome such as “See Phone.” The payment application must follow the Outcome Parameter Set and User Interface Request Data returned by the kernel, display the required message, and perform the second-tap flow when instructed.

Avoid hard-coded timing and message logic copied from another kernel. Drive the user experience from the certified kernel outputs.

Why a kernel asks to use the contact interface

An instruction to use contact does not always mean “amount too high.” Common causes include:

  • The contactless transaction limit was exceeded.
  • The card returned 6985 during Get Processing Options.
  • Required PDOL or TTQ data is missing or inconsistent.
  • The AIP has an invalid length.
  • The Application File Locator (AFL) is malformed.
  • Mandatory data for the selected transaction path is missing.
  • ODA failed and the card/kernel rules require another interface.

Collect the APDU trace and the kernel outcome data before changing limits. Raising a limit will not fix malformed card data, an unsupported path, or an authentication failure.

CVM selection is a compatibility decision

For Visa Kernel 3-style processing, the Card Transaction Qualifiers (CTQ, tag 9F6C) and TTQ express card and terminal capabilities or preferences. The kernel selects from mutually supported methods according to its specification and configuration.

For Mastercard Kernel 2, CVM selection can depend on:

  • The CVM List, tag 8E
  • Whether on-device CVM was performed
  • The transaction amount relative to the CVM limit
  • DF8118 and DF8119
  • Kernel outcome data

Do not reproduce scheme CVM selection in application code. Configure the certified kernel, call it with correct transaction data, and consume its result.

Refunds: AAC does not always mean “stop”

Refund processing is scheme- and acquirer-specific. Some contactless refund flows deliberately produce AAC as the card action-analysis result while the terminal still sends the refund online. In that context, AAC completes the card-side processing; it is not necessarily the final business outcome.

The payment application should therefore:

  1. Set the correct refund/credit transaction type required by the scheme and acquirer.
  2. Supply the refunded amount consistently.
  3. Follow the certified kernel’s refund flow.
  4. Build the online message expected by the host.
  5. Interpret the card cryptogram in the context of the refund flow—not as a universal instruction to abandon the transaction.

Avoid manipulating action codes or replacing CDOL data unless that procedure is explicitly supported by the kernel vendor, scheme certification profile, and acquirer. Such workarounds can change certified behavior and create interoperability failures.

Integration checklist

  1. Maintain per-kernel, per-AID limit configuration.
  2. Test values below, equal to, and above every limit.
  3. Advertise only CVMs the terminal can actually complete.
  4. Implement CDCVM and second-tap UX from kernel outcome data.
  5. Log TTQ, CTQ, AIP, outcome parameters, UI requests, and APDU status words.
  6. Treat “use contact” as a diagnostic outcome, not only as a limit failure.
  7. Certify refund behavior with the acquirer and each supported scheme.

References

Editorial note

EMV and the EMV Contactless Indicator are trademarks of EMVCo, LLC. Payment-scheme product names and marks belong to their respective owners. Before publication, verify all vendor-specific API behavior against the currently deployed, certified kernel version and confirm scheme/acquirer requirements for the target market.