NFC Retries Don't Need Re-Auth Under PSD2

Understanding session-based authentication in contactless payments

Back to all posts

When building mobile payment experiences, we constantly face the tension between security requirements and user experience. Recently, I was asked to weigh in on a specific question: Should users need to re-authenticate when retrying an NFC payment that failed due to a hasty tap?

The scenario is familiar to anyone who's used contactless payments: you unlock your phone, tap it on the terminal, but you pulled away too quickly and the transaction fails. Now you need to retry. Should you have to unlock again, or can you simply tap once more?

This isn't just a UX question: it's a regulatory one. The answer requires understanding what Strong Customer Authentication (SCA) actually means under PSD2, and how proximity payments differ from remote ones.

What the Regulations Actually Require

PSD2 Article 97(1)(b) requires that SCA be applied when a payer initiates an electronic payment transaction. Delegated Regulation (EU) 2018/389 Article 4 specifies that SCA must use two-factor authentication (2FA) and result in the generation of an authentication code that is accepted only once.

Here's the key insight: SCA is not the same thing as the act of unlocking your phone.

When you unlock the SDK with biometrics or a PIN, you're performing 2FA. But that unlock action doesn't generate an authentication code. The authentication code is actually the cryptogram that gets sent to the payment network when you tap your phone on the terminal.

This distinction matters because it means SCA happens when the cryptogram is generated, not when you unlock your phone.

The Session-Based Authentication Model

The question then becomes: does PSD2 require a 1:1 relationship between 2FA operations and authentication codes?

I'd argue it doesn't, and here's why:

First, there's no explicit requirement in the regulations that 2FA must be executed exclusively for each authentication code. PSD2 Article 97(1)(b) requires that SCA be in effect when payment initiation occurs. It doesn't mandate that 2FA be re-executed for each payment attempt.

Second, we have a precedent in EMV chip-and-PIN cards. When you insert a chip card and enter your PIN, that constitutes a single 2FA execution. But the card can generate multiple cryptograms (ARQCs: authorization request cryptograms) for retry attempts without requiring card removal and PIN re-entry. Each cryptogram uses a different Application Transaction Counter (ATC) value and is unique and accepted only once. Presumably, card network implementations comply with PSD2.

The parallel to mobile NFC payments is clear: a single SDK unlock can "cover" multiple tap attempts, as long as each tap generates a unique cryptogram that's accepted only once.

Why Proximity Payments Are Different

An important detail: this analysis assumes the authentication occurs entirely locally on the phone without network connectivity. If any network communication is required during authentication, the transaction may be classified as remote and would require dynamic linking under PSD2 Article 97(2). See this post for more on the topic.

But for true proximity payments (i.e., where the phone doesn't need network access to complete authentication) dynamic linking isn't required. This is confirmed by EBA opinions Q&A 2020_5247 and Q&A 2020_5367.

This means the "swipe to confirm" step you see in some payment apps isn't actually required for regulatory compliance in proximity payments. (Though it might still be a good UX choice for other reasons.)

The Implementation Reality

So from a regulatory perspective, multiple taps under a single unlock are compliant because:

1. Each tap generates a unique cryptogram (the authentication code)
2. Each cryptogram is accepted only once by the payment network
3. Each cryptogram is tied to a single payment attempt
4. The cryptogram can only be generated after 2FA has been completed
5. Each tap demonstrates the payer's consent for that specific payment

Risk Management and Timeout Considerations

While regulations don't mandate it, maintaining a session timeout is prudent risk management. For example, a 4-minute timeout would be reasonably conservative compared to the 5-minute limit specified in Delegated Regulation (EU) 2018/389 Article 4(3)(d) for account access scenarios.

The key take-home message is that payment failures shouldn't necessarily trigger a full SDK relock. That creates unnecessary friction for users. However, payment failures also shouldn't reset the timeout clock: the session should still expire after the original timeout period.

There's also the matter of lockout after repeated failed authentication attempts. Delegated Regulation (EU) 2018/389 Article 4(3)(b) requires temporarily disallowing unlocks after at most 5 failed 2FA attempts. That specific restriction is about failed unlocks though, not failed payment taps.

A Note on Cryptogram Generation

One question that might arise: what if we used the same cryptogram for multiple tap attempts instead of generating a new one each time?

While that would technically still be compliant (one authentication code per 2FA process), it's unnecessarily constraining. Generating a new cryptogram for each tap is the safer approach because:

• The payment network will reject duplicate cryptograms
• Each tap attempt can be uniquely tracked and audited
• It aligns with how chip cards work (incrementing ATC for each attempt)

The Bottom Line

Multiple NFC tap attempts following a single 2FA unlock are in my opinion compliant with PSD2, particularly when failures are due to communication issues rather than authorization problems.

This isn't about finding loopholes in regulations. It's about understanding what the regulations actually require versus what we might assume they require. The goal of PSD2 is to ensure strong authentication and prevent fraud, not to create unnecessary friction in legitimate payment scenarios.

When designing payment UX, we should focus on the principle: SCA must be in effect during payment initiation. That doesn't necessarily mean 2FA must be re-executed before every retry.

Of course, this analysis is my interpretation of the regulations. If you're implementing something similar, you should validate these conclusions with your legal counsel, particularly confirming that your implementation truly qualifies as a proximity payment with no network dependency during authentication.