INTERNATIONAL MARKETS (EMEA) PRODUCT ADVISORY CREDIT CARD CARRIER VALIDATION - PA358

Transcription

1 INTERNATIONAL MARKETS (EMEA) PRODUCT ADVISORY CREDIT CARD CARRIER VALIDATION - PA358 Version: 2 Reason for Issue: Update - Doc updated 21 Dec 2006 Who: What: Where: All Galileo subscribers Enhancement to allow credit cards accepted by an airline to be validated by system control tables Globally

2 OVERVIEW On the Galileo system, the Carrier credit card acceptance policy is currently a manual process for travel agents. If an agent makes a mistake, the BSP will change the form of payment to cash and the agency would be required to pay. This can negatively impact the travel agency monetary funds and can require additional work to recover the costs. Currently on the Galileo system, there is no carrier credit card acceptance policy enforced. Agents may enter any type of credit card as payment in the Galileo system, of; which no validation occurs. If an agent wishes to verify a carrier s credit card acceptance policy, they must either contact the carrier directly or manually verify in the Galileo system. KEY FEATURES With this enhancement, the carrier credit card acceptance policy will be an automated process with validation done within the Galileo host. DETAIL Carriers advise Galileo what credit cards they accept and if any of these credit cards have point of sale limitations. A list of these acceptable credit cards is stored in and accessed by Galileo whenever the form of payment is credit card. This applies to document issuance/tkp, filed fare update/tmu, manual credit card authorization/jv and automated MCO/MCOP. Carriers can elect to store their list of acceptable credit cards in the Galileo Airline Agreement Record/AAR. Updated records reflect the carrier s credit card acceptance policy immediately following the name and account code. A sample input and display is shown below: INPUT: >DT/AAR/DIS-XX (XX - CARRIER CODE) RESPONSE: AIRLINE AGREEMENT RECORD FOR: XX NAME: SAMPLE AIRLINES ACCT CODE: 123 CREDIT CARD ACCEPTANCE: AX DC TP VI AGREEMENTS WITH: AA AC BA KL UA US

3 In the previous example, Sample Airlines accepts American Express, Diners Club, UATP and Visa. Galileo retrieves the plating carrier which validates acceptance of the credit card against the Airline Agreement Record. If the credit card is not accepted by the plating carrier an agent alert appears. Credit Verification The credit card verification JV/V input will support credit card acceptance enhancement when the airline merchant/m is part of the entry. Sample entry: JVAX /D1206/V1.00/MBA Credit Authorization (automated) The credit card authorization request that is part of ticketing will support the credit card acceptance enhancement. Sample entry: TKP; MCOP Credit Authorization (manual) The credit card authorization request JV/T input will support the credit card acceptance enhancement when the airline merchant/m is part of the entry. Sample entry: JVAX /D1206/T2.00/MBA Booking File The Form of Payment field/f. will not support the credit card acceptance enhancement. The booking process allows a card type not accepted to be entered. Validation will occur at the time of document issuance. The F. entry will continue to operate as per current functionality and validation will occur at time of ticket/mco issuance provided no authorisation code has been entered. The Form of Payment Override field/f.cc will not support the credit card acceptance enhancement, as it by-passes the Galileo system s credit card authorization logic. Validation will not occur at the time of document issuance. F.CC will continue to operate as per current functionality. Filed Fare The ticketing Form of Payment modifier/f will support the credit card acceptance enhancement, as part of the TMU entry when the plating/validating carrier/c modifier is present. This includes the Multiple Receivables/*MR screen. The Form of Payment override modifier/fcc will not support the credit card acceptance enhancement as it by-passes the Galileo system s credit card authorization logic. Validation will not occur at the time of document issuance. FCC will continue to operate as per current functionality. A filed fare restore/ff@r input will not support the credit card acceptance enhancement. Validation will occur at the time of document issuance. FF@R will continue to operate as per current functionality.

4 Ticket Exchanges/Re-issue The re-issue process will support the credit card acceptance enhancement, as it is part of the ticketing/tkp. The exchange fill-in screen/*ex has not been modified. The Original FOP field shall function as it does today, the field is free form. Queue Ticketing Queue ticketing/tkpq will support the credit card acceptance enhancement and will follow the normal failure logic. Automated MCO Automated OPATB MCO/TKPMCOXXX and MCOP will support the credit card acceptance enhancement at the time of document issuance. Automated Refunds Automated Refund inputs will not check the credit card acceptance enhancement, (includes all of the TRN string of entries for refunds). Viewpoint Where the functions described above are accessed using Viewpoint, the conditions described above will still apply. Airline Agreement Record/AAR There are two (2) levels of the Airline Agreement Record/AAR, collectively referred to as AAR, being introduced on the Galileo system for credit card acceptance processing: 1) Airline 2) BSP The airline level is maintained by Galileo on behalf of and at the direction of the carrier s head office. The BSP level is maintained by Galileo at the direction of the IATA/local BSP management. The information maintained in these records determines if the credit card presented as the form of payment during fulfilment is honoured. AAR processing ensures the document will be processed by the BSP and settled by the BSP/carrier as a credit card sale. This will reduce the number of transactions the BSP converts from credit sales to cash sales. Please note Airlines may accept more or less card types then the BSP can process or the BSP can accept more or less card types then the airline may accept. These are the card type codes used and support by Galileo. These are the codes that will be seen in the AAR: AX/American Express CA/MasterCard DC/Diners Club JC/Japanese Credit Bureau TP/UATP VI/Visa XX/Nil or None Blank all credit card types are accepted

5 Examples of the Airline level AAR from AG duty code: Carrier has not filed their acceptance policy with Galileo (table is empty). In this scenario all credit card types are accepted for Sample Airways for all points of sale/country level. Carrier states they don t accept credit card as a form of payment. When an airline does not accept credit card as a form of payment, XX is displayed in the AAR table. In this scenario no credit cards are accepted for Sample Airways for all points of sale/country level.

6 Carrier has filed their acceptance policy. In this scenario only the displayed credit card types are acceptable. Example of the BSP level AAR from AG duty code: In this scenario BSP XX can accept and process the following card types on behalf of their airline members. Please note the BSP name and number / ACCT CODE are Galileo s internal numbering convention and unique to Galileo. The BSP number is the same number used in the AAT TYPE field. The BSP table does not support point of sale restrictions. In markets where a BSP represents multiple countries, only one BSP table will exist. Also, BSP processing is at the BSP level and not the point of sale country level. When the airline record is blank and the BSP record is blank then all card types processed by Galileo are accepted.

7 When the airline record is blank and the BSP record is populated then the card types identified in the BSP record are accepted. When the airline record is blank and the BSP record is XX then no card types are accepted. When the airline record is XX and the BSP record is blank, populated or XX then no cards types are accepted. When the airline record is populated and the BSP record is blank then the cards types in the airline record are accepted. When the airline record is populated and the BSP record is populated then only the matching card types are accepted. All FCC (credit card override) inputs will by-pass the above stated Airline Agreement Record rules since the credit card acceptance enhancement will not be implemented for FCC inputs. The usage of the manual approval code/a sub-modifier does not impact the above stated Airline Agreement Record rules. AAR Inputs Travel Agency/AG Duty Code Travel agents/ag duty code users only have the ability to view Airline Agreement Records. Agents will not be allowed to manipulate/change/update/delete/or add to the Airline Agreement Records. Travel agent/ag duty code user has access to the following entry: DT/AAR/DIS-YY YY in the /DIS-YY is the IATA 2 digit carrier code

8 These inputs assume the internal (Galileo assigned) BSP number and ISO code from the AAT. These assumptions are used to return a qualified AAR display to the user. The qualified display is based on data in the airline record; along with any point of sale exceptions and data in the BSP record. Travel agents will only see the card types that are valid in their market place/point of sale. In this qualified AAR display 6 card types are valid (input DT/AAR/DIS-YY). YY = IATA 2 digit carrier code. Terminal Emulation/TE Credit Verification The manual JV/V input will support credit card acceptance when the airline merchant is included in the input; JVccnnn/V1.00/MMYY/Mxx. (MMYY = credit card expiration month and year, xx = the IATA 2 digit carrier code) The verification input will be enhanced to check for credit card acceptance and if passes to continue with current logic and agent responses. If verification fails credit card acceptance then returns error: CARD TYPE NOT VALID FOR USE BY AIRLINE. Credit Authorization (manual) The manual JV/T input will support credit card acceptance when the airline merchant is included in the input; JVccnnn/T2.00/MMYY/Mxx. cc = credit card 2 letter code, nnn = credit card number, MMYY = credit card expiration month and year, xx = IATA 2 digit carrier code. The authorization request input will be enhanced to check for credit card acceptance and if passes to continue with current logic and agent responses.

9 The manual JV/T input with a T0.00 value will be enhanced to check for credit card acceptance if passes to continue with current logic and agent response: AUTHORIZATION REFUSED CONTACT VENDOR. If fails credit card acceptance then return error: CARD TYPE NOT VALID FOR USE BY AIRLINE. Error Response CARD TYPE NOT VALID FOR USE BY AIRLINE (used with JV/V, JV/T and TMU entries) FOP SELECTED NOT AUTHORIZED WITH XX (xx is carrier code) (used with TKP and MCOP entries INVALID TA PSUEDO CITY CODE (used with DT/AAR display entry) REFUSE CREDIT CONTACT VENDOR (used with JV/V, JV/T and TMU entries) However, error responses can vary by credit card type, due to unique processing/validation by each Credit Card Company. Below are examples of valid responses and error responses by credit card type. Following are examples of responses by credit card type: 1. Visa and Mastercard supply one response for card acceptance/validation and one response for CVV acceptance/validation: When using valid card number only (no CVV): OK When using valid card number and valid CVV: OK M CARD SECURITY CODE MATCHED When using valid card number and incorrect CVV: OK N CARD SECURITY CODE NOT MATCHED OR on some occasions: REFUSE CREDIT CONTACT VENDOR When using invalid card number alone and with invalid CVV: REFUSE CREDIT CONTACT VENDOR 2. UATP / TP / Diners supplies only one response as does not have CVV validation at this time: When using valid credit card number APPROVED OK 9113

10 When using invalid card number REFUSE CREDIT CONTACT VENDOR Note : Diners are currently in the midst of implementing CVV support, so some cards may do a CVV check, and respond accordingly. 3. American Express Supplies one response for acceptance/validation and CVV: When using valid credit card number and CVV APPROVED OK When using invalid card number and with invalid CVV: REFUSE CREDIT CONTACT VENDOR APIs and Structured Data Credit Verification <CreditValidation_2_0> and CRDVAL01 will support credit card acceptance when the airline merchant is included in the message. A new response message is added: 2 CARD TYPE NOT VALID FOR USE BY AIRLINE Credit Authorization - <CreditCardVerification_2_0> and DPR02CRDAUT will support credit card acceptance, when the airline merchant is included in the message. The verification part of this message will also support credit card acceptance. A new response message is added: 2 CARD TYPE NOT VALID FOR USE BY AIRLINE Please note All FCC (credit card override) inputs will by-pass the credit card acceptance or Airline Agreement Record rules. Please note The presence of a manual approval code does not by-pass the AAR rules. ASSOCIATED PRODUCTS Not applicable NOTES If you have tested the new functionality related to CVV validation for credit card authorisation you may have found some apparent anomalies. For instance; if you submit an authorisation request to Visa including a CVV number it is possible that the amount can be approved but that the CVV can be rejected.

11 It may be surprising, but this is, in fact, valid functionality. We have approached all 6 card issuers that we deal with and discovered that there are several possible scenarios. Card Scenario Result Visa and MasterCard UATP JCB American Express Valid CVV - amount too high for card available credit. Invalid CVV amount within available credit Valid CVV amount within available credit Invalid CVV amount to high for card available credit. Does not use CVV at this time. Cards do have CVV numbers but our authorisation provider (SITA) does not have that functionality for JCB. Diners Club TBA TBA CVV validates OK but authorisation is refused. CVV rejects authorisation passes. CVV validates OK and authorisation passes. Both CVV and authorisation fail. Only authorisation is returned. CVV cannot be validated. In all cases returns a single response indicating whether the card may be accepted or not.

12 You will have recognised that there is a significant possibility of confusion and agent error with Visa and MasterCard. For instance, if the agent receives an amount authorisation but the CVV is rejected because it has been mistyped by the user the temptation will be to change the CVV and resend the whole request again. However, this will have the effect of asking for authorisation a 2 nd time which will once again reduce the available credit on the card and, if the card no longer has available credit, may result in the CVV being validated but the authorisation refused! The resolution which has been recommended to us is that agents should be advised to send two requests when dealing with Visa and MasterCard. The first one will have a zero amount and include the CVV number. This will validate the CVV without affecting the available credit on the card. The 2 nd request will be the existing authorisation request, including the amount but excluding the CVV to obtain amount authorisation. It is absolutely imperative that agents are advised that any rejection must be followed up with a telephone call to the card authorisation centre. What the agents see as rejection messages may simply be the card company indicating they need additional information which can only be obtained by telephone