NFC and contactless limits

1) Basic concepts of NFC/EMV

NFC (contactless) on POS is an EMVCo payment via a radio channel (Visa payWave, Mastercard PayPass, etc.) with a one-time cryptogram and CVM (Cardholder Verification Method).
CVM determines whether holder verification is required and which: No CVM, Offline PIN, Online PIN, CDCVM (Consumer Device CVM - biometrics/device pin in Apple/Google/Samsung Pay).
DPAN/Network Token: Wallets (Apple/Google Pay) use a token instead of a PAN.
Terminal risk-engine: floor limit, offline risk rules, CAPK keys, TAC/IAC (Terminal/Application Action Codes).

2) Where does the "contactless limit without PIN" come from?

1. Card scheme (Visa/MC/etc.) - establishes CVM rules and kernel compatibility.

2. Regulator/market - may limit the No-CVM amount (e.g. in the EU, UK, etc. - its thresholds).

3. Terminal parameters - core config (CVM Limit, Floor Limit, Velocity/Cumulative counters).

4. Issuer/card - risk profiles, off-services, counters (number of transactions in a row without SCA and/or total threshold).

Important: the limit applies to No CVM physical card transactions. Once CDCVM is applied, it is already "strongly authenticated" and the No-CVM threshold is not relevant.

3) Why Apple/Google Pay is often "unlimited"

CDCVM = biometrics/device pin confirmed on phone/watch. This is in accordance with the SCA and is considered a full holder verification.
For transactions with CDCVM, the terminal receives an indication that the CVM has been completed, so no No-CVM amount restrictions apply (payment is possible for any amount, if the issuer approves).
Exceptions: terminal/core does not support CDCVM, wallet turned off biometrics, transit/offline scripts, local regulatory rules.

4) Offline limits and cumulative counters

Floor limit - the threshold to which the terminal can theoretically allow offline authorization (in contactless, the settings are often zero, but the settings depend).
Cumulative/Velocity counters - the number of consecutive operations without SCA or their total value. After exhaustion, the terminal/issuer requires a PIN/online.
Offline PINs in contactless are not supported by all cards/terminals; more often going online and requesting an Online PIN.

5) Regulatory framework (guidelines)

PSD2/SCA (EEA): contact and contactless operations without SCA are allowed with thresholds (for example, up to ~ €50 at a time and a total of up to ~ €150/or N operations in a row - landmarks; exact values depend on local bank/market implementation). SCA (PIN/CDCVM) is → required.
UK/other markets: No-CVM's own limits (historically raised).
Transit/Open-loop (metro, buses): special Transport Settings - allowed No CVM at high throughput, offline risk mechanisms and subsequent post-authorization/aggregation. "Unusual" statuses and late deniles are possible.

6) Typical CVM case stages

Physical card, purchase below No-CVM threshold: fast tap, no PIN.
Physical card, above the No-CVM threshold: the terminal requests a PIN/signature or transfers to contact/online.
Apple/Google Pay (CDCVM): biometrics completed - the limit is actually "removed," but the issuer can still refuse according to its own rules/risk.
Wearables: usually CDCVM via PIN devices when "unlocking" and constantly wearing; after removing the device, a second PIN is required.

7) Risks and antifraud

No-CVM of card loss/theft: Issuers compensate but hold counters/velocity to limit damage.
Offline terminal solutions: increase UX, but carry the risk of "late" failure during subsequent online verification.
CDCVM reduces risk (SCA), increases the approve rate, but does not exclude emitter/regulatory blocking for MCC/geo/scoring.

8) UX patterns at the checkout

Display the statuses: "Bring a card/phone," "Confirm on the device," "Enter PIN."

If decline is above the threshold, suggest "Repeat with PIN" or "Pay with wallet (Apple/Google Pay)."

In transit - clear texts "Tap in/Tap out," "Card clash" (several cards/wallets at the same time).

9) Terminal setup checklist (acquirer/merchant)

1. Cores: current EMV contactless kernels, CAPK, circuit parameters (Visa/MC/...); regular updates.
2. CVM Limit/Floor Limit/Velocity: agree with the bank and local rules; Enable CDCVM support.
3. Online-preference: for high-risk - forced online; for transit - transport profile.
4. Follbeck logic: when the threshold is exceeded, the PIN/signature/contact insert request is →.
5. Logs/telemetry: reason for requesting PIN (No-CVM exceeded/counters), share of CDCVM, offline solutions, approve rate.

6. UX: understandable promptas on the display; for wallets - prompt "Confirm on iPhone/watch/Android."

7. Test cases: amounts below/above the threshold, N consecutive tap without PIN (counters triggered), CDCVM payment, offline window, transit profile.

10) Features of verticals

Transit/ticketing: priority speed, zero/minimum UI; often separate tariffs/post-clearing procedures.
Hotels/rentals: it is better to conduct prepauthorizations and incremental caps online/online with SCA; contactless "tap-and-go" is only appropriate on final write-offs.
iGaming/quasi-cache: offline is rarely relevant; at MCC risk, emitters can selectively refuse even with CDCVM.

11) KPIs and operational metrics

Approval rate by cut: card vs wallets (CDCVM), below/above No-CVM, offline solutions.
Share of CDCVM and its contribution to conversion.
PIN-prompts rate (how many operations the PIN required) and impact on service speed.
Late declines (after offline permissions), chargeback rate for No-CVM.
Transit KPIs: throughput (taps/min), tap-on/tap-off match, revenue protection.

12) Quick Answers for Support/Operations

"Why no PIN for a large amount?" - CDCVM is made in the wallet; it's SCA.
"Why did you ask for a small PIN?" - counters were triggered or the terminal demanded SCA according to the rules.
"Why didn't the phone work?" - terminal/core does not support CDCVM, wallet is blocked, there is no network for online, card clash.

13) Summary/practical conclusions

No-CVM limit is a threshold only for operations without holder verification; it is not applicable for CDCVM.
Configure CDCVM-enabled terminals, update cores and parameters (CVM/Floor/Velocity).
Consider local regulatory thresholds and circuit rules; keep different profiles (retail vs transit).
Monitor approve rate/CDCVM-share/PIN-prompts and reduce offline risks.

In communication and UI, make the reasons for PIN requests transparent and offer wallets as a way to pass SCA without a "limit."