Secure Customer Authentication

Issue 

In May 2020, acting on behalf of its members across the banking and finance industry, UK Finance published guidance for Strong Customer Authentication specific to the Travel & Hospitality sector. 

Their guidance documentation states: 

“This communication provides important information for businesses of all sizes looking to avoid customers experiencing declined e-commerce transactions after the UK’s Strong Customer Authentication enforcement deadline of 14 September 2021 and the EU’s deadline of the 31 December 2020. After this point card issuers will begin to decline non-compliant transactions. We actively encourage participants outlined in the above section to read the content of this communication and to get in touch with your payment provider (otherwise known as an acquirer or gateway). This should be done with urgency due to the implementation lead times and testing period required.” 

The purpose of this change request is to ensure that NDC standards, practice and guidance relating to customer authentication are in line with those of: 

• Other stakeholders in the value chain, for example: 
  • Card schemes 
  • Payment service providers 
  • Digital wallet providers 
  • Technology providers (in the wider payments space) 
  • Others 
• Other entities in the travel and hospitality sectors, for example: 
  • Travel agents 
  • Hotels 
  • Car hire providers 
  • Others 

So that airlines implementing the latest NDC standards do not experience an increase in declined e-commerce transactions once enforcement commences. The new enforcement date is 14 September 2021 in the UK and 31 December 2020 across the rest of the EU. As a result, UK card issuers will be required to decline all non-SCA-compliant transactions after 14 September 2021. In the run up to these dates, some markets will introduce soft decline mechanisms for transactions above a certain value. As a result, all airlines, sellers and technology providers using NDC and One Order: 

• Should be ready to support SCA in advance of these dates 
• Must be ready to support SCA from these dates 

Business Requirements 

Background 

Strong Customer Authentication (SCA) is a set of rules that defines how individuals and businesses confirm their identity when making purchases online using more than one of the following factors: 

• Something you know – such as a password or phrase 
• Something you have – such as a token generator 
• Something you are – such as biometric data

Its purpose is to protect the individual or business making payment from experiencing payment fraud. Following its implementation, individuals or businesses shopping online will need to undertake extra steps to confirm their identity when paying. 

All parties involved in a payment transaction are required to enable the payer to authenticate their actions in a manner compliant with the underlying regulation. UK SCA determines 3 different scenarios for the Travel & Hospitality Industry. These map to three existing industry models 

This document outlines 4 key requirements for SCA within NDC: 

1. An ability for an airline to determine whether authentication is required for a payment 
2. An ability for a seller to initiate the authentication of a payer making a payment 
3. An ability for an airline to create the authorization request for a payment made by an authenticated payer 
4. An ability for an airline to request a seller to initiate the authentication request after authorization 

Whilst these requirements must be met across a number of different authentication / authorization models, this document is only concerned with scenarios where the Seller Initiates Authentication on behalf of the Airline who will authorise payment (Scenario A and C above). At present, this represents two authentication models: 

• Seller authenticates via 3DS 2.x OR 
• Seller authenticates via another solution provided by a third party

Across two core payment flows 

1. Shop -> Price -> Order -> Pay 
2. Shop -> Price -> Pay -> Order

Requirements 

1. Determine Need to Authenticate Payment 

A function to determine a need to authenticate has two core uses. One is to determine prior to authorization whether to authenticate or not. The other is to determine how to authenticate when authorization was refused with a ‘soft decline’, but decline indicates that authentication is required. Requirement 1 outlines the former. The latter is outlined in requirement 4. 

• As a seller, I need to know if I must authenticate a payer or not so that an airline can create the authorization request 
• As an airline, I need to determine what type of payment transaction a seller has initiated so that I can determine whether authentication is needed before going to authorization 

2. Authenticate Payer 

Once it has been determined that a customer needs to authenticate, a seller needs to initiate authentication. This requirement assumes that the seller knows he should authenticate the customer prior to a customer committing to pay for an order. 

• As an airline, I may need to provide information to the seller so that they can authenticate a customer 
• As a seller, I need to authenticate a customer so that an airline can proceed to authorization 
• As a seller, I need to return information about the authentication to the airline so that they can proceed to authorization 

3. Authorize Payment by Authenticated payer 

Once a customer has been authenticated, the airline will need to provide information about the customer authentication in the authorization request. 

• As an airline, I need to receive the authentication attempt result from the seller so that I can proceed to authorization 

4. Communicate Need to Authenticate a Payment 

If either: 

1. An Airline determines that a payer needs to be authenticated prior to attempting authorization OR 
2. An authorization is declined due to a lack of authentication (‘a soft decline’) 

An airline should indicate to the seller that the payer must authenticate to complete the payment transaction. 

• As an airline, I need to inform a seller that authentication is needed in order to proceed to authorization of a given payment transaction 
• As a seller, I need to allow the payer to authenticate in order to complete a given payment transaction

 Business Process Model

Business Functions

Provide Card Authentication Method

Provide Card Authentication Criteria

Provide Card Payment Details

Provide Card Payment Data

 Provide Card Authentication Data

Provide Card Payment Status Data

Request Payer Authentication

Data Model

New Elements

New Value Types