WIXLIB

Overview card payment current workflowOctober 2016

DISCLAIMER NOTICEThe information contained in this document is subject to review in the light ofchanging business needs of the industry, government requirements andregulations. Both Edgar, Dunn & Company and IATA take no responsibility for thecompleteness of this document. Readers are solely responsible for all decisionsmade based on this document

Current generic payment workflows: the following slides describe asimplified view of the current generic payment workflowsThree workflows are mapped out describingthe current situation:Each workflow shows three key steps1 Step 1: the authorisation request /authentication stage for a paymenttransaction Direct sales via airline.com(airline Merchant of Record - MOR)(out of scope of this project) Indirect sales via travel agent This is typically undertaken at time ofpurchase (i.e. when consumers/buyersprovide their payment details and proceedwith the “buy” button) Step 2: exchange of payment data used forclearing (so called “invoice file” or “capture”)Travel Agent MOR, with a BSP “cash”transaction (out of scope of this project)Airline MOR, with a BSP “card” transaction This typically involves a daily exchange offiles (e.g. at the end of each business day) Step 3: financial settlement whereby themerchant is paid Note: in an airline environment, the authorisation/capture is usuallybased on a dual message communication (versus a single message,where the authorisation and capture happen simultaneously)3This is typically a daily credit transfer intothe merchant’s bank account X days afterclearing

Current generic payment workflowsDirect sales via airline.com - Airline is MORCurrent situation - Direct sales - Airline MOR - Generic flowTypical transaction flows of an airline ticket purchase with a bank card through direct rline ticketLegendData exchangedFinancial Airline5 3IssuerAuth4AuthPaymentnetworkTxndatafile4 51. The buyer purchases an airline ticket on airline.com2. 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 thePSP 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 issuer4. 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 paymentnetwork - Clearing5. Settlement takes place from the issuer, via the the payment network; then to the acquirer/PSP and airline4

Current generic payment workflowsIndirect sales via travel agent - B2.1 Travel Agent MOR, with a BSP “cash” transactionCurrent situation - Indirect sales - TA MOR Generic flowLegendBuyerData exchangedIATA BSP on daily basisFinancial data1Purchaseairline ticketTravelAgency6 6 1IATA’sBSPGDS“cash”sales44AuthIssuer 52Txndatafile332Auth Paymentnetwork5TravelAgent’sAcquirerTxndatafile 5Airline1. The buyer books and purchases an airline ticket via atravel agent, which checks availability and pricing viaGDS. The travel agent reports a BSP “cash” sale inthe GDS and buyer pays the travel agent by e.g. card2. The travel agent requests an authorisation andreceives a response, involving the payment network,the travel agent’s acquirer and the issuer3. Transaction data file is sent from the travel agent’sacquirer to the issuer via the payment network4. Simultaneously to 3., transaction reporting via theBSP to the airline5. Daily settlement of airline ticket from the issuer viathe payment network; and then from the travelagent’s acquirer to the travel agent6. Weekly/monthly settlement transactions “cash” viathe BSPNote: in order to simplify the flows, EDC described thepayment flow in a non-e-commerce environment, hence noPSP involved5

Current generic payment workflowsIndirect sales via travel agent - B2.2 Airline MOR, with a BSP “card” transactionCurrent situation - Indirect sales - Airline MOR –Generic flowBuyer1Data exchangedIATA BSP on daily basisFinancial dataPurchaseairline ticket1TravelAgency4GDS“card”salesIssuer2 3Authlog5 2AuthPaymentnetwork5Txndatafile66Note: in order to simplify the flows, EDC describedthe payment flow in a non-e-commerce ��sBSP4 Legend61. The buyer books and purchases an airline ticketvia a travel agent, which checks availability andpricing via GDS. The travel agent reports a BSP“card” sale in the GDS2. GDS requests an authorisation via a direct linkwith payment networks, receives a response andsends the response back to the Travel agent3. Payment network sends, in some cases, theauthorisation files (or Auth log - TC33s) on a dailybasis to airline’s acquirer4. Transaction reporting via the GDS through theBSP to the airline and to the airline’s acquirer ordirectly to the airline’s acquirer5. Transaction data file is sent from the airline’sacquirer to the issuer via the payment network6. Daily settlement of airline ticket from the issuervia the payment network; and then from theairline’s acquirer to the airline

Currently, for some of the use cases, the infrastructure and set up inplace do not enable airlines to be the MORCurrent 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 transferPurchasing an airline ticket via a travelagent - Use casesTravel agent is MORAirline is MORE-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 7

E-commerce “unsecured” transaction- Airline is MORCurrent situation - Indirect sales - Airline MOR e-commerce unsecured transactionBuyerLegend1Data exchangedIATA BSP on daily basisFinancial dataPaying airlineticket with acard 2a2PaymentpageHosted2b pageIssuerTxndatafile32ORAuthTravelAgent’s PSPAuthlog4Airline’sacquirer3Auth 56AirlinePaymentnetwork5 686 1. The buyer books and purchases an airlineticket via a travel agent’s website, whichchecks availability and pricing via GDS.2. The buyer is on the TA’s payment page orredirected to the PSP’s hosted page (ifthis set up is in place)3. GDS or Travel Agent’s PSP requests anauthorisation and receives a response,involving the payment network and issuer4. Payment network sends, in some cases,the authorisation files (Auth log - TC33s)on a daily basis to the airline’s acquirer5. Transaction data file is sent to the issuer,by the GDS via the BSP, airline/airline’sacquiring bank and payment network clearing6. Settlement taking place between theissuer, via the payment network; then tothe airline’s acquirer, which credits theairline’s account

E-commerce “secured” transaction- Travel agent is MORCurrent situation - Indirect sales - TA MOR- e-commerce secured transactionPaying airlineBuyer1ticket with a cardonline 8 83TravelAgency3D gent’s PSP54Auth5Paymentnetwork 7TravelAgent’sAcquirerTxndatafile 7Note: it is currently not possible for the airline to be MORin the case of a secured transaction, with 3D Secure9Airline6 74AuthIATA’sBSPGDS“cash”salesLegendData exchangedIATA BSP on daily basisFinancial data1. The buyer purchases an airline ticket via a travelagent’s website, which checks availability andpricing via GDS2. The buyer is redirected to the PSP’s hosted page(if this set up is in place)3. Cardholder authentication (3D Secure) - linkbetween the travel agent’s PSP and the issuer4. The travel agent’s PSP requests an authorisationand receives a response, involving the paymentnetwork, the travel agent’s acquirer and the issuer5. Transaction data file is sent by the acquirer to theissuer, via the payment network - Clearing6. Reporting of cash sales via the BSP7. Daily settlement of airline ticket from issuer via thepayment network; and then to the travel agent’sacquirer, which credits the travel agent’s account8. Weekly/monthly settlement transaction “cash” viathe BSP

E-commerce purchase with a wallet, e.g. PayPal- Travel agent is MORLegendCurrent situation - Indirect sales - TA MOR - walletTechnical flowsCustomer experiencePayPal – General flows for direct connections to PayPal (API calls) when a buyer purchases on travel agent’swebsite1ConfirmationpageCheckout page- Amount- Currency- (invoiceorder ID)2bToken35If immediatedebitCapture6Funds transfer789Token2aPayPal serverPayPal loginpageConfirmation ofthe payment4AuthorisationBatch with othertransactionsFlows in details:1.2.3.4.5.6.The buyer clicks on the PayPal button2a) API call to PayPal’s server2b) A token is created and sent to the travel agentThe buyer is redirected to PayPal login page for authenticationThe buyer confirms the transaction, chooses form of payment and thedelivery address (list of payment methods available varies per country)The travel agent receives the authentication confirmationThe travel agent requests the authorisation (or can skip and go toimmediate debit / capture)7.8.9.10Authorisation accepted (but does not provide any guarantee)Capture Can be accepted or declined by PayPal – Must be initiatedBEFORE the ticket is issued. If PayPal accepts this transaction, it doesnot provide a full guarantee (to be negotiated with the merchant)A bank transfer is automatically processed the following day to the travelagent’s bank account. As soon as the settlement is processed, the travelagent would receive a daily file (via secure FTP server) with all thetransactions occurred or cancelled from PayPal, with details forreconciliationSource: PayPal

E-commerce purchase with a bank transfer, (iDEAL)- Travel agent is MORCurrent situation - Indirect sales TA MOR - bank transfer1. The buyer selects the items to purchase2. The buyer selects iDeal as a paymentmethod and selects his issuing bank1 Booking and paymentTravel3.An iDeal message is exchanged between9 10BuyerAgencythe travel agent’s acquirer and the issuer24. The buyer is redirected to the bank of hisRedirectchoice (his issuer). The issuer presents the4‘landing page’ to the buyer, which offersthe option to complete the iDeal payment36on the online banking interfaceOnlineiDeal messages5. The buyer logs in, confirms the pre-filledbanking 5Real timeiDeal payment and authorises itCPSP6. Once completed, the issuer immediatelysends a payment guarantee to the travelagency via the acquirerReal time7.After completion of the payment, the buyerTravel agent’siDeal messagesTravel36is shown the result of the payment by theaccountIssuerAgent’screditedissuer. The buyer is redirected back, by hisAcquirerFund transfer via e.g.bank, to the travel agent’s web page usingSEPA credit transferCustomer makes iDealMerchant enters intothe merchantReturnURLpayments from a bank account(within few days)an iDeal agreement8. The travel agent displays the buyer theat a licensed issuerwith a licensedconfirmation of the iDeal paymentacquirer9. Reporting of cash transaction sales via theNote 1: CPSP collecting payment service provider - with a role of collecting funds - optional to select oneBSPiDeal is offered by around 8-9 acquiring banks and 60 CPSPs. If a merchant would like to offer iDeal to10. Weekly/monthly settlement “cash”customers, they will need to agree a contract with one of these parties. They will also provide thetransactions via the BSP78merchants with support in the technical implementation of iDeal within their online checkout systemNote 2: The buyer sees CPSP as the beneficiary of the payment on bank’s statement; and the “airline” ina reference field/line. This is standard procedure for all iDEAL payments ( 50%) with a CPSP involved11Source: iDEAL