Overview card payment current workflow

October 2016

DISCLAIMER NOTICE

The information contained in this document is subject to review in the light of

changing business needs of the industry, government requirements and

regulations. Both Edgar, Dunn & Company and IATA take no responsibility for the

completeness of this document. Readers are solely responsible for all decisions

made based on this document

Current generic payment workflows: the following slides describe a simplified view of the current generic payment workflows

Three workflows are mapped out describing

the current situation:

Direct sales via airline.com

(airline = Merchant of Record - MOR)

(out of scope of this project)

Indirect sales via travel agent

• Travel Agent = MOR, with a BSP “cash”

transaction (out of scope of this project)

• Airline = MOR, with a BSP “card” transaction

Each workflow shows three key steps1

Step 1: the authorisation request /

authentication stage for a payment

transaction

• This is typically undertaken at time of

purchase (i.e. when consumers/buyers

provide their payment details and proceed

with the “buy” button)

Step 2: exchange of payment data used for

clearing (so called “invoice file” or “capture”)

• This typically involves a daily exchange of

files (e.g. at the end of each business day)

Step 3: financial settlement whereby the

merchant is paid

• This is typically a daily credit transfer into

the merchant’s bank account X days after

clearing

3

Note: in an airline environment, the authorisation/capture is usually based on a dual message communication (versus a single message, where the authorisation and capture happen simultaneously)

Current generic payment workflowsDirect sales via airline.com - Airline is MOR

Typical transaction flows of an airline ticket purchase with a bank card through direct channel

4

Buyer

Airline.com

Payment

page

Airline’s

PSP

Hosted

pageAirline’s

Acquirer

Auth

Airline

IssuerAuth

$

$

1

1. The buyer purchases an airline ticket on airline.com

2. The buyer pays on the airline’s payment page or is redirected to the PSP’s hosted page (if this set up is in place - a token is often created by the

PSP and shared with the merchant)

3. The PSP requests an authorisation and receives a response, involving the payment network, the airline’s acquirer and the issuer

4. Transaction data file (can be referred to as “capture” or as “billing file”) is sent from the airline’s acquirer/PSP to the issuer, via the payment

network - Clearing

5. Settlement takes place from the issuer, via the the payment network; then to the acquirer/PSP and airline

34

Payment

network

3

Txn data file

5

5

2a 2bOR

2

Current situation - Direct sales - Airline = MOR - Generic flow

Data exchanged

Financial data

Legend

Purchase airline ticket

4

Current generic payment workflows

Indirect sales via travel agent - B2.1 Travel Agent = MOR, with a BSP “cash” transaction

5

Travel

Agency GDS

“cash” sales

Travel

Agent’s

Acquirer

Auth

Buyer

Issuer

Payment

network

Auth

IATA’s

BSP Airline

$ $

$ $

$

Purchase airline ticket

1. The buyer books and purchases an airline ticket via a

travel agent, which checks availability and pricing via

GDS. The travel agent reports a BSP “cash” sale in

the GDS and buyer pays the travel agent by e.g. card

2. The travel agent requests an authorisation and

receives a response, involving the payment network,

the travel agent’s acquirer and the issuer

3. Transaction data file is sent from the travel agent’s

acquirer to the issuer via the payment network

4. Simultaneously to 3., transaction reporting via the

BSP to the airline

5. Daily settlement of airline ticket from the issuer via

the payment network; and then from the travel

agent’s acquirer to the travel agent

6. Weekly/monthly settlement transactions “cash” via

the BSP

1

2

2

4

Txn data file

5

61

4

33

5

6

Txn data file

Note: in order to simplify the flows, EDC described the

payment flow in a non-e-commerce environment, hence no

PSP involved

Data exchanged

IATA BSP on daily basisFinancial data

Legend

Current situation - Indirect sales - TA = MOR -Generic flow

5

Current generic payment workflows Indirect sales via travel agent - B2.2 Airline = MOR, with a BSP “card” transaction

6

Travel

Agency GDS

“card” sales

Airline’s

AcquirerAuth

Buyer

Issuer

Payment

network

Auth

IATA’s

BSP Airline

$

$

$

Purchase airline ticket

1. The buyer books and purchases an airline ticket

via a travel agent, which checks availability and

pricing via GDS. The travel agent reports a BSP

“card” sale in the GDS

2. GDS requests an authorisation via a direct link

with payment networks, receives a response and

sends the response back to the Travel agent

3. Payment network sends, in some cases, the

authorisation files (or Auth log - TC33s) on a daily

basis to airline’s acquirer

4. Transaction reporting via the GDS through the

BSP to the airline and to the airline’s acquirer or

directly to the airline’s acquirer

5. Transaction data file is sent from the airline’s

acquirer to the issuer via the payment network

6. Daily settlement of airline ticket from the issuer

via the payment network; and then from the

airline’s acquirer to the airline

2

2

4

6

1

4

5

6

6

4

3Auth log

5Txn data file

Note: in order to simplify the flows, EDC described

the payment flow in a non-e-commerce environment

Data exchanged

IATA BSP on daily basisFinancial data

Legend

Current situation - Indirect sales - Airline = MOR –

Generic flow1

OR

Currently, for some of the use cases, the infrastructure and set up in place do not enable airlines to be the MOR

Current situation: purchase of an airline ticket via a travel agent

The airline cannot be the merchant of record in three cases:

• Purchase online with a “secured” authentication including, e.g. 3D Secure authentication

• Purchase online with a wallet such as PayPal

• Purchase online where the buyer pays with a bank transfer

7

Purchasing an airline ticket via a travel agent - Use cases

Travel agent is MOR Airline is MOR

E-commerce “unsecured” transaction ✔ ✔

E-commerce “secured” transaction ✔ ✕

E-commerce purchase with a wallet ✔ ✕

E-commerce purchase with a bank transfer ✔ ✕

Call centre purchase with a lodge card ✔ ✔

E-commerce “unsecured” transaction - Airline is MOR

8

Travel

Agency GDS

“card” sales

Payment

page

Hosted

page

Travel

Agent’s PSPAirline’s

acquirer

Auth

Buyer

Issuer

Payment

network

Auth

IATA’s

BSP Airline

$ $

Paying airline ticket with a card online

1. The buyer books and purchases an airline

ticket via a travel agent’s website, which

checks availability and pricing via GDS.

2. The buyer is on the TA’s payment page or

redirected to the PSP’s hosted page (if

this set up is in place)

3. GDS or Travel Agent’s PSP requests an

authorisation and receives a response,

involving the payment network and issuer

4. Payment network sends, in some cases,

the authorisation files (Auth log - TC33s)

on a daily basis to the airline’s acquirer

5. Transaction data file is sent to the issuer,

by the GDS via the BSP, airline/airline’s

acquiring bank and payment network -

clearing

6. Settlement taking place between the

issuer, via the payment network; then to

the airline’s acquirer, which credits the

airline’s account

1

2

3

5

5

Txn data file

6

1

32

55

6

$

6

2a

2b

O

R

4Auth log

Data exchanged

IATA BSP on daily basisFinancial data

Legend

Current situation - Indirect sales - Airline = MOR -e-commerce unsecured transaction

E-commerce “secured” transaction

- Travel agent is MOR

9

Travel

Agency GDS

“cash” sales

Hosted

page

Travel

Agent’s PSPTravel

Agent’s

Acquirer

Auth

Buyer

Payment

network

Auth

IATA’s

BSP Airline

$

$ $

$

3D Secure

Issuer

1. The buyer purchases an airline ticket via a travel

agent’s website, which checks availability and

pricing via GDS

2. The buyer is redirected to the PSP’s hosted page

(if this set up is in place)

3. Cardholder authentication (3D Secure) - link

between the travel agent’s PSP and the issuer

4. The travel agent’s PSP requests an authorisation

and receives a response, involving the payment

network, the travel agent’s acquirer and the issuer

5. Transaction data file is sent by the acquirer to the

issuer, via the payment network - Clearing

6. Reporting of cash sales via the BSP

7. Daily settlement of airline ticket from issuer via the

payment network; and then to the travel agent’s

acquirer, which credits the travel agent’s account

8. Weekly/monthly settlement transaction “cash” via

the BSP

1

2

45

6

7

8

3

Txn data file

Payment

page

Note: it is currently not possible for the airline to be MOR in the case of a secured transaction, with 3D Secure

Data exchanged

IATA BSP on daily basisFinancial data

Legend

2a

2b

O

R

1

3

4

7

$ 8

7

Current situation - Indirect sales - TA = MOR - e-commerce secured transaction

Paying airline ticket with a card

online

5

6

E-commerce purchase with a wallet, e.g. PayPal - Travel agent is MOR

10

Checkout page

PayPal serverConfirmation of

the paymentPayPal login

page

Confirmation page

Capture

Authorisation

- Amount- Currency- (invoice

order ID) Token

1. The buyer clicks on the PayPal button

2. 2a) API call to PayPal’s server

2b) A token is created and sent to the travel agent

3. The buyer is redirected to PayPal login page for authentication

4. The buyer confirms the transaction, chooses form of payment and the

delivery address (list of payment methods available varies per country)

5. The travel agent receives the authentication confirmation

6. The travel agent requests the authorisation (or can skip and go to

immediate debit / capture)

2aToken

Batch with other transactions

Funds transfer

2b

1

3

4

5 6 7

If immediate debit

8 9

Flows in details:

Legend

Customer experienceTechnical flows

PayPal – General flows for direct connections to PayPal (API calls) when a buyer purchases on travel agent’s website

7. Authorisation accepted (but does not provide any guarantee)

8. Capture Can be accepted or declined by PayPal – Must be initiated

BEFORE the ticket is issued. If PayPal accepts this transaction, it does

not provide a full guarantee (to be negotiated with the merchant)

9. A bank transfer is automatically processed the following day to the travel

agent’s bank account. As soon as the settlement is processed, the travel

agent would receive a daily file (via secure FTP server) with all the

transactions occurred or cancelled from PayPal, with details for

reconciliation Source: PayPal

Current situation - Indirect sales - TA = MOR - wallet

E-commerce purchase with a bank transfer, (iDEAL) - Travel agent is MOR

11

Note 1: CPSP = collecting payment service provider - with a role of collecting funds - optional to select one

iDeal is offered by around 8-9 acquiring banks and 60 CPSPs. If a merchant would like to offer iDeal to

customers, they will need to agree a contract with one of these parties. They will also provide the

merchants with support in the technical implementation of iDeal within their online checkout system

Note 2: The buyer sees CPSP as the beneficiary of the payment on bank’s statement; and the “airline” in

a reference field/line. This is standard procedure for all iDEAL payments (~ 50%) with a CPSP involved

1. The buyer selects the items to purchase

2. The buyer selects iDeal as a payment

method and selects his issuing bank

3. An iDeal message is exchanged between

the travel agent’s acquirer and the issuer

4. The buyer is redirected to the bank of his

choice (his issuer). The issuer presents the

‘landing page’ to the buyer, which offers

the option to complete the iDeal payment

on the online banking interface

5. The buyer logs in, confirms the pre-filled

iDeal payment and authorises it

6. Once completed, the issuer immediately

sends a payment guarantee to the travel

agency via the acquirer

7. After completion of the payment, the buyer

is shown the result of the payment by the

issuer. The buyer is redirected back, by his

bank, to the travel agent’s web page using

the merchantReturnURL

8. The travel agent displays the buyer the

confirmation of the iDeal payment

9. Reporting of cash transaction sales via the

BSP

10. Weekly/monthly settlement “cash”

transactions via the BSP

Source: iDEAL

Current situation - Indirect sales -TA = MOR - bank transfer

Customer makes iDeal payments from a bank account

at a licensed issuer

Booking and payment1

2

7 8

Travel

AgencyBuyer 9 10

Merchant enters into

an iDeal agreement

with a licensed

acquirer

iDeal messages

Fund transfer via e.g.

SEPA credit transfer

(within few days)

Real time

3 6Travel agent’s

account

creditedIssuer

Travel

Agent’s

Acquirer

Online

banking

4

5

Redirect

iDeal messages

Real time

36

CPSP

Call center purchase with a lodge card - Airline is MOR

12

TMC Call

centre

Travel

Manageme

nt

Company

(TMC)

GDS

“card” sales

Airline’s

acquirer

Auth

Buyer

Issuer

Payment

network

Auth

IATA’s

BSP Airline

$ $

Paying with a lodge card via

call centre

1. The buyer calls the TMC to book an airline ticket

and indicates that he will pay by lodge card

2. TMC checks availability and pricing via GDS.

TMC accesses the buyer’s profile. The TMC

reports a BSP “card” sale in the GDS

3. The GDS or TMC’s PSP requests an authorisation

and receives a response, involving the payment

network and the issuer

4. Payment network sends, in some cases, the

authorisation files (Auth log - TC33s) on a daily

basis to airline’s acquirer

5. Transaction reporting via the GDS through the

BSP to the airline and to the airline’s acquirer or

directly to the airline’s acquirer

6. Transaction data file is sent to the issuer, by the

airline’s acquiring bank and via payment network

- clearing

7. Settlement taking place between the issuer, via

the the payment network; then to the airline’s

acquirer crediting the airline’s account

1

3

5

7

1

32

66

7

$ 71

4Auth log

Data exchanged

IATA BSP on daily basisFinancial data

Legend

5

Current situation - Indirect sales - Airline = MOR

call centre with lodge card

O

R5

October 2016