Secure Customer Authentication
  • 04 Sep 2020
  • 8 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Secure Customer Authentication

  • Dark
    Light
  • PDF

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. 

Example of Secure Customer Authentication
A card issuer (e.g. a bank) may require a customer to enter a passcode they have provided via text message in order to verify their purchase prior to payment authorization. If this step is not carried out, payment is likely to be refused.

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 

ScenarioDescriptionDetail Existing Industry capability
AThe Booking Agent authenticates the cardholder, and the supplier of the travel & hospitality service collects the payment.In this scenario the Booking Agent must send the authentication and other associated payment data to the merchant (via intermediaries) and the merchant requests payment authorization to collect the funds associated with the booking or to get confirmation of the authenticated MIT agreement from the issuerNDC with customer payment
BThe Booking Agent authenticates the cardholder and collects the payment from the customer on behalf of the Travel & Hospitality supplier.In this scenario, the Booking Agent after authentication requests the payment authorization to collect the funds associated with the booking or to get confirmation of the authenticated MIT agreement from the issuer. It then passes associated payment data to the supplier to enable it to collect any additional payments it is authorised to collect, as Merchant Initiated Transactions (MITs), under the terms of the booking agreement with the customerGDS-intermediated model
CNo authentication is performed by the Booking Agent as the transaction is out of scope (one leg out or MOTO, or anonymous card) or qualifies for an exemption (e.g.: secure corporate payment) and the supplier of the travel & hospitality service collects the payment.In this scenario, the data relative to the out of scope/exemption must be passed onwards to the Travel & Hospitality supplier along with other payment data for it to perform its own authorization request as the merchant of record.

Note: Booking Agents should not request exemptions at the authentication stage of transactions for which they are not collecting the funds unless they have a specific agreement with the travel supplier (the merchant) and its acquirer to do so. This is essential as the use of exemptions is the prerogative of the merchant’s acquirer, not that of an Agent. The secure corporate payment exemption can generally be used when the booking is initiated from a dedicated corporate processes which is not available to consumers and which is considered secure. Typically only Travel Management Companies (TMC’s) will be permitted to use this exemption. 
NDC with customer payment AND GDS-intermediated model
Note
It is assumed that a capability to determine whether a transaction falls into Category A or Category C is in scope for NDC. Similarly, it is assumed that Category B is out of scope for NDC.

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
Note
As well as NDC messages between airline and sellers, OneOrder messages may need to be updated to support Secure Customer Authentication. If necessary, this will be covered in a new CR.

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

Initiator

Airline

Description

The Airline is providing Card Authentication method to the Seller 

Action(s)

Inform

Actors

Airline

Seller

Domain

Shop/Price

 

Key data

  • Authentication method
    • 3DS1.x
    • 3DS2.x

Result

The seller knows the authentication method that would be needed to authenticate a payer’s given payment method

Provide Card Authentication Criteria

Initiator

Airline

Description

The Airline is providing Card Authentication Criteria to the seller 

Action(s)

Inform

Actors

Airline

Seller

Domain

Shop/Price

 

Key data

  • Data identified in CR129

Result

The seller knows the authentication criteria needed to authenticate a payer given their payment method

Provide Card Payment Details

Initiator

Customer

Description

The customer is providing the Card Payment details to the seller

Action(s)

Pay

Actors

Payer

Seller

Domain

Order

 

Key data

  • Card number
  • Expiry date
  • Card Verification Value

Result

The payer is able to provide Payment Card information to the seller

Provide Card Payment Data

Initiator

Seller

Description

The seller is providing Card Payment details to the airline

Action(s)

Pay

Actors

Seller

Airline

Domain

Order

 

Key data

  • Card number/ Token Number
  • Card Brand
  • Card expiry date
  • CVV2/CVC2 value

Result

The seller is able to pass Payment Card information to the airline

 Provide Card Authentication Data

Initiator

Seller

Description

The Seller is providing Card Authentication data to the airline

Action(s)

Pay

Actors

Seller

Airline

Domain

Order

 

Key data

  • Data identified in CR129
  • Data specified by UKFA
    • Payment Trx Channel Code
    • Card Number Collection Code
    • Payer Authentication Exemption Code
    • Payer Authentication Failure To Complete Code
    • Authentication Token Value

 

Result

The seller is able to pass authentication data to the airline

Provide Card Payment Status Data

Initiator

Airline

Description

The Airline provides payment status information back to the seller

Action(s)

Pay

Actors

Airline

Seller

Domain

Order

 

Key data

  • Order action success
  • Order action failure
  • OrderID (Optional)
  • Payment action success
  • Payment action failure
  • Payment ID (Optional)

Result

The airline has received an authorization approval code or an error code and the seller is informed of the payment status

Request Payer Authentication

Initiator

Airline

Description

The airline notifies the seller that a payment requires that the payer must authenticate before authorisation will succeed

Action(s)

Pay

Actors

Airline

Seller

Domain

Order

 

Key data

  • Payment ID (Optional)
  • Order ID (Optional)
  • Data outlined in “Provide Card Authentication Criteria”

Result

The seller knows that a payer must authenticate for a given payment transaction to proceed.

Data Model

New Elements

New Value Types