PSD2: POS Consumer Scans are Still Remote

Back to all posts

Many mobile payment scheme rely on consumer scans (a.k.a. "scan to pay") to function, where the payment terminal (or e-commerce checkout page) renders a QR code for the user to scan for payment initiation. Counter-intuitively, PSD2 classifies all consumer scans as remote even if they take place at the merchant's physical location (i.e., a traditional "card present" scenario). As a result, such payments must conform to regulatory constraints governing remote payments, such as the dynamic linking of SCA.

Consumer Scans are Always Remote

Typically, when a consumer scans the QR code on the merchant's terminal, communication and authentication path does not rely on a local interface like NFC or a card reader. The merchant terminal is passive in this scenario: it does not receive or send transaction data directly.

Because PSD2 guidance classifies transactions based on technical setup and communication channel rather than physical presence, optical payments are in effect classified as "remote transactions".

More specifically per EBA Q&A 2020_5367, where it was asked whether a payment could qualify as a proximity payment when a proximity technology (e.g., NFC, QR code, etc.) is used to exchange payment information between the user's mobile device and the merchant's terminal (after which a mobile network is used for payer authentication, e.g. via a mobile app). The EBA responded:

In the case described by the submitter, the EBA understands that the payer would initiate a credit transfer at a point of sale (PoS) with contactless funcionality [or a QR code] with the authentication of the payer taking place on a mobile application and requiring a mobilenetwork. [In the case of QR-code payments] the initiation of the payment transaction, including the authentication of the payment service user (PSU), is dependent on the use of internet [...]. Therefore, such a transaction should be considered as a remote payment transaction and would require the application of the dynamic linking requirements under Article 97(2) PSD2.

Remote Payments Require Dynamically-Linked SCA

Article 97(2) PSD2 requires PSPs to apply SCA that includes elements, which dynamically link the transaction to a specific amount and a specific payee:

Member States shall ensure that, for electronic remote payment transactions, payment service providers apply strong customer authentication that includes elements which dynamically link the transaction to a specific amount and a specific payee.

Further, per article 5(1)(a) of the Delegated Regulation (EU) 2018/389 covering Dynamic Linking:

1. Where payment service providers apply strong customer authentication in accordance with Article 97(2) of Directive (EU) 2015/2366, in addition to the requirements of Article 4 of this Regulation, they shall also adopt security measures that meet each of the following requirements:
   1. the payer is made aware of the amount of the payment transaction and of the payee;
   2. the authentication code generated is specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction;
   3. the authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the identity of the payee agreed to by the payer;
   4. any change to the amount or the payee results in the invalidation of the authentication code generated.

As a consequence, a payment initiated by consumer scan must always result in a round-trip from the payment scheme to the user's device after the scan so that the SCA can be dynamically linked to the payment: SCA typically takes place prior to the scan action (as it is usually performed as an "unlock" functionality to access the ability to scan in the first place), so it must be linked to the payment authorization after the fact. Naturally, this linking must related to the specific merchant and payment info.