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

contact@corebaseit.com (Vincent Bevia) — Thu, 03 Sep 2026 16:45:00 +0200

Contactless problems often begin when several independent controls are collapsed into one “contactless limit.” The reader evaluates different thresholds for different decisions: whether the contactless interface may be used, whether cardholder verification is required, and whether the transaction should go online.

This post separates those limits, then covers Consumer Device Cardholder Verification Method (CDCVM) second-tap flows, “use contact” outcomes, CVM selection, and refund paths where AAC is not a universal stop signal. The contactless kernel model matches POINT OF SALE ARCHITECTURE (the book), Chapter 3: EMVCo Entry Point (Book B) selects Kernel 2 for Mastercard AIDs and Kernel 3 for Visa AIDs. Chapter 4 covers CDCVM as device-side verification for wallet and high-value contactless flows.

The limits answer different questions

Limit	Decision
Contactless transaction limit	May this amount use the contactless interface?
Reader CVM required limit	Is cardholder verification required?
Reader contactless floor limit	Should the transaction request online authorization?
Terminal floor limit	General terminal risk-management threshold; use is kernel- and configuration-dependent

Boundary rules matter. One kernel or scheme profile may use >=, while another may use >. Do not 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 once Combination Selection has bound the AID to Kernel 2, Kernel 3, or another Book C kernel.

These online/offline thresholds are related to, but not identical to, contact Terminal Action Analysis. For the ARQC/TC/AAC decision model after risk checks, see Online vs Offline EMV Transactions and Why an EMV Contact Transaction Was Declined.

CDCVM and the “see phone” flow

CDCVM is performed on the consumer device—passcode or biometric—rather than on the terminal PIN pad. In the book, Chapter 4, that is the point of CDCVM: device authentication can satisfy CVM without a redundant POS prompt when the path supports it.

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

The consumer taps before completing device verification.
The terminal tells the consumer to verify on the device.
The original transaction is terminated or paused as required by the kernel outcome.
The consumer verifies and presents the same device again.
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 for the AID in play.

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 (conditions of use not satisfied).
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. When the failure is cryptographic rather than limit-related, start with CAPK and certificate recovery—see CAPKs: The Cryptographic Trust Anchors Behind Every EMV Transaction.

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. Advertise only CVMs the terminal can actually complete; that constraint shows up again in SoftPOS and L3 scope discussions in L3 certification paths.

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.

Interpretation note: treat this as a profile-specific rule, not a universal EMV contact rule. Confirm the refund path against the certified kernel, scheme contactless guide, and acquirer host specification for each market you ship.

The payment application should therefore:

Set the correct refund/credit transaction type required by the scheme and acquirer.
Supply the refunded amount consistently.
Follow the certified kernel’s refund flow.
Build the online message expected by the host.
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

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

References

POINT OF SALE ARCHITECTURE: A Practical Guide to Secure, Certifiable POS Systems — Chapter 3: EMV Principles (Entry Point / Kernel ID taxonomy, proprietary tags such as TTQ/CTQ); Chapter 4: Wallets and APMs (CDCVM); Chapter 17: Testing and Certification (TTQ profiles and CVM scope).
Online vs Offline EMV Transactions
Why an EMV Contact Transaction Was Declined
CAPKs: The Cryptographic Trust Anchors Behind Every EMV Transaction
L3 certification paths: C-TAP, SmartPOS, SoftPOS
EMVCo — EMV Contactless Chip
EMVCo — Specifications and Associated Bulletins
Visa — Transaction Acceptance Device Guide
Visa — VSDC and Visa payWave U.S. Acquirer Implementation Guide
EMV Contactless Specifications for Payment Systems, Book A: Architecture and General Requirements
EMV Contactless Specifications for Payment Systems, Book B: Entry Point Specification
EMV Contactless Specifications for Payment Systems, Book C-2: Kernel 2 Specification
EMV Contactless Specifications for Payment Systems, Book C-3: Kernel 3 Specification

Ttq on Corebaseit — Design System Engineering · POS · Payments · Security