Thanks to PSD2, payments can now be initiated by merchants and be confirmed by customers using an app. But how does this actually work and how can this be secure? This post describes how passwordless payment works in practice and elaborates on the mechanisms and standards behind such a solution.
The protocol is referred to as “payment initiation” by EU 2015/2366, the second Payment Services Directive (PSD2) issued by the European Commission and the European Banking Authority. The Berlin Group issued standards for PSD2-compliant payments within a payment ecosystem. The system described below complies with the so-called NextGenPSD2 XS2A Decoupled SCA Approach: Implicit Start of the Authorisation Process. Note that UK Open Banking standardised a similar mechanism through CIBA (see our FAQ).
Illustrating passwordless approval of payment initiation
We’ll illustrate a potential passwordless payment with a (fictional) bank BestPay, a customer of Passwordless Authenticator. We’ll use a story about Hanna, a buyer at a (fictional) online shop called BestBuys that is affiliated with BestPay. The story goes as follows…
“Hanna received an invitation from her bank to activate passwordless payments. She installed the app from BestPay on her personal phone.
All she needed to do was to provide her consent and activate the phone. She was told that this activation actually started a cryptographic process. In this process, her phone generated secret keys that were used to establish a super-secure channel between her phone and the bank. The secret keys are safely stored in the vault on her phone and cannot be retrieved by a hacker or so.
She found herself in need of going for run. Down at the park, it started raining and she thought: it’s time to buy new shoes.
Surfing the web, she found BestBuys offering summer sales up to 50%. They also happened to be affiliated with her bank, so she wanted to try out passwordless payments.
She found a pair of Fly&Run shoes and ordered them immediately.
The online shop now gave her a choice to pay the traditional way or the ‘flash’ way. Paying the traditional way would mean that her browser would be redirected to her bank.
She now chose the Flash Checkout option.
The Flash Checkout invited her to open the payment app of BestPay.
By scanning the QR code the payment app obtained the payment request. Hanna was now invited to confirm the purchase, which would unlock the vault of her phone and execute a cryptographic exchange with her bank.
This actually completed the transaction. Her bank would transfer the money to BestBuys and BestBuys can book the purchase as ‘paid.’
Hanna is a happy customer of both BestBuys and her bank BestPay thanks to this frictionless handling of her payment.
How does payment approval work?
Rather than entering a password into the browser or app that is then sent to the server, Passwordless Authenticator lets the user give their consent and approve transactions simply by using their trusted device. We’ll use the TrustBuilder Mobile Authenticator solution as an example – see here.
The Passwordless Authenticator process to the bank (or third party payment services provider) is basically broken up in two disjoint steps:
- First, the user authenticates to their trusted mobile to prove they are the owner and are present. This is local and device-specific and is typically done using a PIN code, fingerprint or face-id.
- Then, the Passwordless Authenticator client within the app authenticates itself to the Mobile Authenticator server without exchanging passwords or long-term secrets but by executing a cryptographic process using secret keys in the vault of the device.
This means that user authentication is out-of-band, i.e., using a different device and channel. Given the security of the vault and the biometrics on mobile phones, security of the Passwordless Authenticator is superior to traditional methods. The only requirement of this model is that the Passwordless Authenticator client must be installed on the trusted mobile and be registered at the Passwordless Authenticator server beforehand.
The authentication between the Passwordless Authenticator client and the server adopts a SIGMA cryptographic protocol (“SIGn-and-MAc”). The SIGMA family of key-exchange protocols offer perfect forward secrecy which means that session keys remain protected even in case the long-term secrets used for the key exchange are compromised. To ensure secrecy of the mobile client as well as mutual authentication between the mobile client and the server, these protocols adopt Diffie-Hellman and add a secure hash and signature of the request. As such, the SIGMA protocol of the Mobile Authenticator establishes a trusted channel between the mobile client and the authentication server.
From a PSD2 perspective, Passwordless Authenticator adds consent and signing of the payment request according to the SCA requirements for PSD2.
The process with Passwordless Authenticator is as follows. In this process we assume the user has previously installed and activated the payment app that contains the Passwordless Authenticator client as described further.
- During the check-out process, the merchant will initiate the payment request with the bank of the buyer. This process may happen through an acquirer and/or a third-party payment service provider – see below. The result is a Payment Initiation Response.
- Using the Payment Initiation Response, a QR code is generated that contains the payment details. The merchant shows the QR code and invites the buyer to use the payment app of their bank.
- The buyer now takes their trusted device and opens the payment app of her bank. By scanning the QR code, the payment details are exchanged between the browser and the Mobile Authenticator client inside the payment app.
- The buyer reviews the payment details and approves/refuses the transaction after which she authenticates herself to her trusted device, e.g. face-id, fingerprint or PIN code. This unlocks the device’s private vault for the Mobile Authenticator client.
- The Mobile Authenticator client uses the secret keys kept in the private vault and opens the trusted channel with the bank. This is done by initiating the Mobile Authenticator protocol. The payment details are then signed and passed on to the Mobile Authenticator server of the bank.
- The Mobile Authenticator server now formally declares that the buyer has approved the payment and the bank can execute the payment.
How does payment app activation work?
The bank (or, in general, a payment service provider) installs the secure Passwordless Authenticator server. They also publish a payment app (or extend their banking app) that contains the Passwordless Authenticator client.
They then invite their customers to install the payment app on a device they trust, i.e. that they own and that has a secure vault for secret keys that only they can unlock. The customer then follows these steps:
- Open the payment app on their device
- Unlock their device’s vault using fingerprint, face-ID, or PIN
- Read and accept the bank’s privacy policy and terms and conditions
- Start the activation process.
The activation process is handled by the Passwordless Authenticator client in collaboration with the Passwordless Authenticator server using the SIGMA-1 cryptographic protocol.
How does payment initiation work?
With EU 2015/2366, the EU issued the second Payment Services Directive (PSD2). Whereas in the UK, the Open Banking initiative standardises PSD2-compliant payment services, the EU set up the Berlin Group, led by EU banks and payment processors.
The European Banking Authority issued a Regulatory Technical Standard (RTS) relative to PSD2, which calls for multi-factor authentication and explicit detailed payer consent in what is called Strong Customer Authentication (SCA). SCA basically adds dynamic linking of transaction details (amount and payee) to the multi-factor authentication of the payer.
The Berlin Group further standardises PSD2-compliant Access-to-Account (XS2A) practices in technical detail. The aforementioned step #1 payment initiation implements the so-called Decoupled SCA Approach: Implicit Start of the Authorisation Process.
This Decoupled SCA Approach: Implicit Start of the Authorisation Process works as follows:
The Secure Customer Authentication (SCA) is performed by the Passwordless Authenticator as described above.
There may be several parties between the merchant and the bank. Payment initiation can, legally speaking, only be done by a licensed Payment Initiation Service Provider (PISP). Large e-merchants may pick the PISP role themselves, but often the PISP role is done by the merchant’s Acquirer or a third-party payment service provider (TPPSP). Also the bank may be an intermediary and be the Account Servicing Payment Service Provider (ASPSP) as a front door to the bank holding the buyer’s account.
A more elaborate process involves token exchange that builds upon OAuth 2. The Berlin Group has standardised this under OAuth2 SCA Approach: Implicit Start of the Authorisation Process with Confirmation Code.
Controlled AI services 