V2User's Guide
|
V2 User's Guide |
This transaction has been created with the objective of providing Amadeus Customers with anautomated solution for the re-issuance of airline ticket after involuntary changes.
Operation Used to create an empty TST manually, only containing most basic information (passenger/ticket information, SATA or OPEN option)
Operation to Authenticate Description Billing Data.
Delete existing TST or TSTs
Eticket Void : This function is used to void an Eticket
Eticket Print: This function is used to request a paper ticket
Eticket History Display: This function displays electronic ticket history
Eticket List Display: This function displays a list of electronic tickets
Eticket Single Display: This function displays a single electronic ticket
This function allows to modify an existing TST.
The Powered Ticket, AlterTSTSegmentAssociation request offers a means of re-setting the links between a TST and its related segments.
Operation used to return information on an existing TST.
Operation used to confirm the creation of the TST after a pricing transaction.
Operation used to check the form of payment made with a credit card and able to obtainan approval code status for the transaction made.
Operation used to check the validity of a Credit Card.
Consists of Get Airport control and Push Airport Control.
Get Airport control allows airport control of ET flight coupons from a carrier to be requested.
Push Airport Control permits the transfer of control of ET flight coupons to a carrier to be requested.
Not applicable
There are currently no known limitations to the actual Interface itself. All functional limitations are listed within the applicable function areas of this document.
Not applicable
Context:
This transaction has been created with the objective of providing Amadeus Customers withan automated solution for the re-issuance of airline ticket after involuntary changes.The AutomaticUpdate function re-prices one passenger for the entire flight itinerary orfor a selected flight itinerary in a newly created or retrieved PNR.The system re-prices one passenger for involuntary reissues/exchanges in accordance with IATA guidelines.
The class of service is obtained automatically from the PNR.The re-pricing concerns E-Ticket documents.This transaction store and create a corresponding TST record which would include all there-issue involuntary data.It is possible to select only one passengerType (infant or Adult) in a PNR and to re-price its itinerary.
It is possible to choose which parts of a segment are to be included in theitinerary pricing.
It is possible to choose which part of the original e-ticket has to be exchanged. Thisselection must begin with the first coupon open for use.
AutomaticUpdate function allows for the following supported operation(s):
Only the involuntary repricing option is supported.
The End-User must be authorized to perform an Amadeus Ticket Update transaction. The officeprofile is checked in order to authorize the Amadeus Ticket Update process and/or redirect theEnd user to the current manual process.
Data availability:
E-Ticket must be accessed in order to retrieve all the necessary data pertaining to the Original document.
Once the retrieval has been done, the process can be performed using old/new information.The AutomaticUpdate function needs the following elements:
If the PNR contains only one passenger (with no infant), the Passenger selection is not mandatory.Therefore, for a PNR with more than one passenger or with infant, the passenger selection is mandatory.
Concerning the Passenger or the segment selection, the tattoo numbers need to be specified.
Depending on the flavor of the API that is used, each query will follow a given structure,the queries for the function operations are clearly explained with data element examples ina generic table view that can be adapted to the specific flavor of the API in use.
It is important to note that the examples in each chapter are only illustrations and aremeant to provide the basis for a better understanding on which fields are mandatory for basicoperation utilisation. It is not a full explanation of every field that can be utilised forthe operation, but rather a guideline to its use.
A TST has been created if the transaction is successful.
In the example we receive the tattoo of the TST element created and also pax and segment tattoo
CM00005 - Check segment number
A segment with the TATTOO number specified in the REF segment is not present in the PNR
CM00011 - Unable to process Process error - normally it should not be related to data fromthe request
CM00258 - Function not supportedRequest a functionality not yet implemented
CM00477 - Invalid format Data specified in the request is not valid, although is OK fromthe message definition
CM01908 - Check passenger number
A segment with the TATTOO number specified in the REFsegment is not present in the PNR
CM01959 - Need PNR A request has been made without a retrieved/newly createdPNR.
CM02230 - Single selection code onlyDifferent passenger types specified in the same REF segment.
CM04070 - Unable to process+ seg name
Process error - normally it should not be related to data fromthe request - the name of the program where error occurred isappended at the end of the message.
Here is an example of query with a passenger selection (pax 1) and a couponselection (coupon 2 and 3).
See "Error Messages" section.
The CreateManualTST request offers a means of creating a TST manually and filling itin with the most basic data. Among this data, there are Passenger/segment/TST/fare tattoo referencenumber, the record locator, and the possibility to flag the TST OPEN or SATA (these are two possibleoptions, one excludes the other).
Not applicable
The other data contained in the TST must be added via updates.
Not applicable
At least one name and one segment must exist in the PNR.
The query must contain the passengers/segments for which TST is created. It is possible to append a SATA or an OPEN option. Below is an example of a SATA option.
The replies received (except error messages) contains TST number and Passenger/segment association
1908 CHECK PASSENGER NUMBER
If passenger number does not match a passenger number in the PNR.
5 CHECK SEGMENT NUMBER
If segment number does not match a segment number in the PNR.
1903 CHECK PASSENGER ASSOCIATION
If there is an overlap
12363 SATA MEMBER CODE NOT FOUND
Create a TST with SATA option for passenger 1, segments 1 and 2.
All standard error messages are outlined in the section, "Error Messages".
The Validate Descriptive Billing data function provides thefoundation, in cooperation with AirPlus in Germany, for DescriptiveBilling when a Payment is made by selected AirPlus Cards * .The descriptive billing information allows a customer to reconciletheir travel expenses into categories, for example by booking date.
This function will be used by all AMADEUS locations that have subscribed to thisfunction with AirPlus when authorization is requested for selectedAirPlus Cards, either in connection with ticket issuance or as a standalone entryor as PNR (Passenger Name Record) Credit card form of payment processing.The Stand Alone Entry is used for any type of service other than automatedtickets or as fallback when Descriptive Billing Data for any reason was notcaptured in connection with Ticket Issuance. It should be notedthat the billing is not performed by AirPlus in Germany and not Amadeus.
*http://www.airplus.com
Not applicable
There is a limit of up to 10 occurrences of attributeDataLabel in the same record.You are limited to 15 characters maximum in length for the accountNumber .
Not applicable
Not applicable
Depending on the flavor of the API that is used, each query will follow a given structure.The queries for the function operations are clearly explained with data element examplesin a generic table view that can be adapted to the specific flavor of the API in use.It is important to note that the examples in each chapter are only illustrations and aremeant to provide the basis for a better understanding on which fields are mandatory forbasic operation utilization. It is not a full explanation of every field that can be utilisedfor the operation, but rather a guideline to its use.
| Data element | Value |
|---|---|
| /returnCode/type | U |
| /returnCode/statusCode | P |
The function returns an acknowledgement of reception, if the data entered bythe end user does not passthe field format validation, then message 'INVALID FIELD LENGTH' is sent.
Validate description billing.
See the section, "Error Messages".
A transitional stored ticket (TST) is a record containing all the ticketinginformation associated to a passenger name record. The system automatically stores information requested from the Fare Server in the TST.
The system creates automatically multiple TST if:
*When the system creates more than oneMST, the output of theTTCcommand is a TST index.Since no pricing data is returned from theFare Server, the TSTs total defaults to zero (0).
If more than one TST exists, the system numbers the TST and appends the TST creation date,office identification and agent sign to the TST.
If a PNR contains more than one TST, active and/ordeleted, a TST INDEX is created by the system and may be displayed bythe user. (TQT)
If only deleted TSTs exist, a TST index is also created showingthe deleted TSTs.
Set Up, Modify Or Delete TST Confidentiality
If no EOS agreement, onlythe office who sets the confidentiality of the TSTcan access, read and update the TST.The Office creating or retrieving a TST (not necessarily the onecreating the PNR) is able to flag the TST as confidential, restrictingthe access of that TST to any other officeAn Asterix is appended to the header line of the PNR meaning thatat least one of the TST(s) present in that PNR is confidential.An asterix is also appended to the confidential TST number(s).
PNR
RP/MUC1A0701/MUC1A0701 BM/PR 9DEC98/0821Z ZL6GMX
AGUIA/MR 2.ELEFANTE/MR
RG 117 Y 09FEB 2 POAGRU HK2 2 1730 1900 *1A/
RG 818 Y 09FEB 2 GRUMIA HK2 2 2355 0455+1 *1A/
TST INDEX
T P/S NAME TOTAL FOP SEGMENTS
* .1 AGUIA/MR EUR 1862.61 CASH 3-4
.2 ELEFANTE/MR EUR 1862.61 CASH 3-4
PC Flag (PNR Change Flag)
Itinerary changes made subsequent to TST creation may be moved from the PNRinto the TST automatically by the system; e.g. schedule change.The TST panel contains a 'PC' flag to alert the user of an itinerary changeto the PNR subsequent to TST creation. The purpose of the flag is to warn theuser to check the fare stored on the TST because of an itinerary change.
Whenever the PNR Change flag is activated under one or several TSTs,(name change, itinerary update etc.),it is simultaneously added to theTQT list associated to the corresponding TST.The two letters 'PC' are displayed in the TST header as well as in the TST index.It can be manually removed by performing aTTF command.
There are two different types of tickets, namely:
Manual Stored Ticket
A manual stored ticket (MST) is aTST which has been created manually (TTI,TTC), oran automatic TST that has been updated manually.
Automatic Stored Ticket
An Automatic Stored Ticket (AST) is automatically created by the system as a resultof a PNR itinerary pricing command. The ticket image is for information only as thesystemuses the TST to issue the ticket an identification is placed on the header line of thePNR to indicate that a TST is attached to a PNR.
If a TST does not exist and a ticketing command, is entered, the system prices theairfare for the PNR (except if the multiple fares exist for the sameclass), creates the TST and the interface recordwhich is sent to the ticketing system to request issuance.
Negociated Fare Data:
Some negociated data are confidential. As such access to this data is restricted in case of Negociated Fares used for pricing;
Base Fare is always accessible
Net Fare and Published Fare are accessible according to the office profile setting.
So, in the response to a TSTdisplay, Base Fare will always be present with codeset B (selling Fare). Net Fare (codeset H) and Published Fare (codeset PU) will only be present if TQN in the office profile is set to Yes.
Remark:
Fare elements of the PNR are not associated to the TST so they are not part of the Edi message of the TST display.
These fare elements can be retrieved with the PNRACC and the pax/segment association of the fare elements can be checked against the one of the TST.
Display TST.
A Fare calculation panel has been created to support an automatic pricing of16 segments which implies a fare calculation line extended to 547 characters.Whenever the Fare calculation line exceeds 247 characters (standard length), asymbol "+" is displayed on the 248 position of the main Ticket panel.
The following fare element information is stored both in the PNR and the TSTwhen using native cryptic entries.
These elements are NOT returned in the Ticket_DisplayTST Reply ,but may be obtained using the PNR_Retrieve.
1st Phase: From March 31st to June 1st
2nd Phase: From June 1st
First phase
Second Phase
TST History.
A newly created or an existing PNR with segments containing ticketing information.
Depending on the flavor of the API that is used, each query will followa given structure. The queries for the function operations are clearly explained with data element examples in a generic table view that can be adapted to the specific flavor of the API in use.
It is important to note that the examples in each chapter are only illustrations and are meant to provide the basis for a better understanding on which fields are mandatory for basic operation utilisation. It is not a full explanation of every field that can be utilised for the operation, but rather a guideline to its use.
It's important to point out that the function DisplayTST can be performed only in an integrated context (i.e in the context PNR).
Not applicable.
Reply Structure
Not applicable.
A Standard ValidateCreditCard response is received.
This example shows how to display all the TST.
See "Error Messages" section.
Display TST with scrolling.
A Standard ValidateCreditCard response.
Scrolling on.
A Standard ValidateCreditCard response.
Display TST with segment selection.
A Standard ValidateCreditCard response.
Display TST with TST select.
A Standard ValidateCreditCard response.
Display TST with passenger selection (including infant).
A Standard ValidateCreditCard response.
Display TST with passenger selection (without infant).
A Standard ValidateCreditCard response.
A transitional stored ticket (TST) is a record containing all the ticketing informationassociated to a passenger name record.
The function DeleteTst allows one or many TSTs present in the PNR to be deleted.It allows deleteTST(s) with TST selection or the passenger or segment selection.
Delete TST
Not applicable.
Not applicable.
A newly created or an existing PNR with segments containing ticketing information.The PNR needs to contain TST(s) to delete.
Depending on the flavor of the API that is used, each query will follow a given structure. The queries for thefunction operations are clearly explained with data element examples in a generic table view that can beadapted to the specific flavor of the API in use.
It is important to note that the examples in each chapter are only illustrations and are meant to provide thebasis for a better understanding of which fields are mandatory for basic operation utilisation. It is not a fullexplanation of every field that can be utilised for the operation, but rather a guideline to its use.
Not applicable.
Not applicable.
Not applicable.
Delete a TST with a TST Tattoo number.
Not applicable.
Delete a TST with a TST number.
Not applicable.
Delete all the TSTs present in the PNR.
Not applicable.
Delete TSTs associated with the passenger selected.
Not applicable.
Delete TSTs associated with the tattoo segment selected.
Not applicable.
Eticket Single Display: This function displays a single electronic ticket
Eticket List Display: This function displays a list of electronic tickets
Eticket History Display: This function displays electronic ticket history
Eticket Print: This function is used to request a paper ticket
Eticket Void : This function is used to void an Eticket
See overview
Ticket number is mandatory field even for Eticket Void, Eticket Print or History display.
Before Eticket Void, Eticket Print or History Display, you have to perform an Eticket Display.
Multi-Etickets display is not available.
TicketPrint function is restricted to US Market.
TWDRT entry is not covered
The user should be familiar with ET functionality and can refer to the IATA Passenger Services Conference Resolutions Manual Resolution 722f (airline) and Resolution 722g (neutral) for more details.
An ET record shall be attached to the AAA
Eticket Single Display
The query shall contain the ET number that is requested to be displayed and the message function 131 for Single Display.
Note: The multi-Etickets Display (up to 9 documents) is not available.
Eticket List Display
The query shall contain the 3-alphanumeric airline code owing the electronic documents which are requested to be displayed and the message function 131 for List Display
Eticket History Display
The query shall contain the ET number whose history is requested to be displayed and the message function 137 for History Display
Eticket Print
The query shall contain the ET number that is requested to be printed and the message function 132 for Print
Eticket Void
The query shall contain the ET number that is requested to be voided and the message function number 133 for Void
The reply acknowledges or rejects the different Eticket follow up requests.
For valid transactions, a message is sent to the ET database of the airline owing the electronic documents. If the ET database reply indicates the request was processed successfully, the system returns:
SALE IS CANCELLED IN REPORTING SYSTEM
Reply Structure
The ReplyExample to the following queries can be found in the operation :
Thefollowing status codes may be present in the reply structure :
| Meaning |
Coupon Status Code in TKTRES 4.1 CPN and in XML |
Equivalent IATA Values |
|---|---|---|
| Coupon notification |
701 |
N |
| Refund taxes/fees/charges only |
710 |
Y |
| Airport Control |
AL |
A |
| Flown/Used |
B |
F |
| Boarded |
BD |
L |
| Check in |
CK |
C |
| Closed |
CLO |
Z |
| Exchanged/reissued |
E ( no mapping needed) |
E |
| Original Issue( open for use) |
I |
O |
| Irregular operation |
IO |
I |
| Not Available |
NAV |
U |
| Print Exchange |
PE |
X |
| Printed |
PR |
P |
| Refunded |
RF |
R |
| Void |
V ( no mapping needed) |
V |
|
Meaning |
Booking Flight Status Code in TKTRES 4.1 RPI and in XML file |
Equivalent IATA Values |
|---|---|---|
| Confirmed |
OK |
OK |
| Requested |
RQ |
RQ |
| Space available | SA | SA |
| (default value) | OK | (other) |
There is below the successfull reply to Eticket Single Display query which can be found in the operations.
The following data indicator values in the FOP segment can be supported in the reply structure :
| Meaning |
Value |
|---|---|
| Non secured print material |
0 |
| ExcSecured print material-originator of request information is required | 1 |
| Old |
2 |
| New |
3 |
| In connection with | 4 |
| Original issue form of payment |
5 |
See specific messages in each section
This function displays electronic ticket history.
You must have displayed the Eticket before.
If you perform the Eticket History Display without performing an Eticket display before, you will get the following error:
NO ET DETAILED RECORD PRESENT
This function displays a list of electronic tickets by CC Number and Passenger Name
See "Error Messages" section.
This function displays a list of electronic tickets by FOID
This function displays a list of electronic tickets by Travel information and Passenger Name
See "Error Messages" section.
This function is used to request a paper ticket.
Thisfunction is restricted to US Market.
"Message Function" 153 is not a valid UseCase
The'PRT' indicator of the Eticket Preferences Tables of the airline you haveissued the Eticket should be set to 'ON', else the error code 915. Thiserror means : 'No Action - processing host cannot support this function'
NB:please note that some airlines have 2 Eticket Preferences tables : a generalone and a specific to US market
This function displays a single electronic ticket
If the ticket number entered in the request does not exist in the airline Eticket Data Base, you get an error with the errorCode 401
In interlining situation, you can get the error NO INTERLINE AGREEMENT BETWEEN CARRIERS with errorCode 75z
This function is used to void an Eticket
If you perform a ticket void directly without displaying the Electronic ticket before, you get the error with errorCode 310:
Ticket arrangement data missing
When the document to void is not available to void ( see with TSR why ), you get the error with errorCode 354.
A Transitional Stored Ticket (TST) is a record containing some ticketing information associated to a passenger name record.
There are Manual Stored Ticket and Automatic Stored Ticket.
A Manual Stored Ticket (MST) is a TST which has been created manually, or an automatic TST that has been updated manually.
An Automatic Stored Ticket (AST) is automatically created by the system as a result of a automatic pricing command.
Modifications can be done on different fields of the TST.
Generally, a TST modified by the request UpdateTST becomes a manual TST, even if there are some exceptions.
In order to use the UpdateTST function, the TST Tattoo number should be used to define which TST in the PNR needs to be modified.
Update TST.
The Update TST function allows to Update ONE TST.
The following fare element information is stored both in the PNR and the TST whenusing native cryptic entries.
These elements are NOT returned in the reply .
Not applicable.
A newly created or an existing PNR with segments containing ticketing information.The TST that needs to be updated should be present in the PNR.
The Update query has the structure that is in fact the sub-structure of the TST display response containing all the potential modified data.
In order to update a TST, the query should contain the iDSequenceNumber (i.e the TSTnumber composed of 32bit) and the ticket image (TST display response) with all the potential modified or not. If an unmodified data is not mentioned in the query,this data will be erased from the TST.
The reply has the same structure as the TST display reply. As we can update only one TST, the TST update Reply provides the Ticket image ofthe updated TST in the same way as the TST display reply.
When you update the TST, please pay attention to the tattoos that you use in the query. For example, you can have some errors when you try updating a TST using a wrong TST reference.
The update TST example
Not applicable.
The Powered Ticket, AlterTSTSegmentAssociation request offers a means of re-setting the links between a TST and its related segments. At creation time a TST must be segment and passenger associated. The segment association is updated with this AlterTSTSegmentAssociation verb.
Not applicable
One TST only can be handled per message.
Not applicable
At least one name, one segment and one TST must exist in the PNR.
The query must contain the list of the new segments that will be associated to the TST and the TST tattoo.
The reply received (except error messages) contains the list of the new segments that have been associated to the TST and the TST tattoo
5 CHECK SEGMENT NUMBER
If segment number does not match a segment number in the PNR.
This example change segment association for TST 1.Once this message has been processed, TST 1 will be associated to segments 2 and 3 from the PNR.If other segments were associated to TST 1, they are removed from it.
See "Error Messages" section.
This function provides Amadeus Customers with an automatic way to create TST.
In the TST, the system automatically stores information obtained from the Fare Server during a previous Pricing transaction.
There are as much as TST created as there are different passenger types and discount codes in the PNR.
Note: A TST (Transitional Stored Ticket) is a record containing all the ticketing information associated to a passenger name record.
The function CreateTSTFromPricing allows the following operation:
Create TST
A maximum of 10 TST can be created for each passenger.
Not applicable.
A pricing transaction must have been performed before.
At least one name and one segment must exist in the PNR .
The query contains the references to the different TST that have to be created. These references have been returned by a previous pricing transaction.
The received reply (except error messages) contains TST number and Passenger association
The reply contains the reference of the TST created with its passenger association.
There are as much as TST created as there are different passenger types and discount codes in the PNR.
Data:
TST Reference (IRV): the reference to the created TST (tattoo number and identification number)
Pax Information (REF): the reference of the passengers that are associated to the TST
In this example, the PNR contains 2 infants and 5 adults in the PNR and there are 4 different passenger types. Here is the reply obtained:
CM00001 - Unable to process
Process error - normally it shouldn't be related with data from the request.
CM00005 - Check segment number
A segment with the TATTOO number specified in the REF segment is not present in the PNR
CM00258 - Function not supported
Request a functionality not yet implemented
CM00339 - Need Name
The PNR does not contain any names.
CM00357 - Link down
A problem of communication between the different systems occurs.
CM00477 - Invalid format
Data specified in the request is not valid, although is OK from the message definition
Examples: recommendation number is not digit.
CM01908 - Check passenger number
A segment with the TATTOO number specified in the REF segment is not present in the PNR
CM01959 - Need PNR.
A request has been made without a retrieved/newly created PNR.
CM01966 - Need itinerary
There is no itinerary in the PNR.
CM02058 - Previous TST exists / Segment Overlap
The TST can not be created because there is an overlap with the existing TST.
The End User has to delete the existing TST if he wants to price the selected recommendation.
CM02230 - Single selection code only
Different passenger types specified in the same REF segment.
CM03052 - Maximum tsts this passenger
The maximum number of TST (10) is reached for a passenger
In this example, the End-User requires for the creation of the 4 TST previously returned by a pricing transaction.
The Powered Ticket, Credit Card Authorization request offers a means of checking theform of payment made with a credit card and is able to obtain an approval code status forthe transaction made.For cards issued in the US and CANADA you can also make an address verification.Credit Card checks can be preformed without the issuance of a ticket.
Important: the address verification field in your office profile * must be setto ON to allow you to use this function. If it is not set the verification process isstopped and an error message is returned. Additionally, an approval code is only valid fora ticket issued on the Day that the approval code was obtained.Once obtained, an Approval cannot be cancelled through the system.
* To know more about the Office Profile please refer to the Powered Profile User's Guide.
This option allows for credit card check as the form of payment.
For the cards issued in the United States of America and in Canada addressverification is performed, therefore to use the Credit Card Check function this field inthe Office Profile * needs to be set.Otherwise, when the function is performed the verificationprocess is stopped and an error message is returned.
* To know more about the Office Profile please refer to the Powered Profile User's Guide.
Not applicable
There are no specific requirements to use Powered Ticket Interface except a valid Credit card.
The following code sets may be used when building a query for theInterface Powered Ticket, Credit Card authorization Function:
| Code | Currency Cardholder Billing |
|---|---|
| 840 | USD |
| Code | AVS Result |
|---|---|
| Y | Exact match (both address and POSTAL code) |
| Z | Partial match on POSTAL code (address does not match) |
| U | CCAVS info not available |
| A | Partial match on address (POSTAL code does not match) |
| N | No match (nor address, nor POSTAL code) |
| R | Retry later (authorization system unavailable) |
| E | Error in transaction (not eligible for CCAVS) |
| S | Service not valid for CCAVS |
When transmitting the Credit Card Authorization request to VISA, in the authorization message the country code is the country code of the point of sale (officeId). But there is the possibility to override this country code with a given one by entering it in the field Country of this verb. This country code override will only work for:
- CA / XS / BZ / EC cards
Country code (Alpha Numeric 2)
FR
GB
If the request was not successful, the CreditCardCheck will respond with an appropriateerror message. The error messages returned depends upon the specific situationencountered, the possible errors that are unique to a specific operation are coveredin the individual operation scenarios within this document.
If you do not specify a currency value in the PriceInfo section, the system defaults toUSD (American dollars). It should also be noted that gaps should not be leftbetween numbers when entering the cardNumber value, as this will cause the systemto report an erroneous error at validation time. However, for clarity in the exampleslisted in this documentspaces have been left to aid in the readability of this document.
| /commonCcData/ccInfo/ cardNumber | 4410 0301 1234 0024 |
This message is the result of a Credit card check digit(last digit of credit card number).For example, the original card number given was 3782 9102 7851 004 and the checkdigit was changed to a number '3', to make the card numbervalid 3782 9102 785 1003.
| 4377 | INVALID ACCOUNT NUMBER |
This message is the result of a Invalid expiry date.
| 1149 | CREDIT CARD EXPIRED |
This message is a result of a missing expiry date in a query.
| 1146 | EXPIRATION DATE MISSING OR INVALID |
Additionally, following errors may be encountered:
| ERROR MESSAGE | CODE | DESCRIPTION |
|---|---|---|
| ERR CC SECURITY ID IS A MATCH | 12677 | Security ID on the back of the CC matches the data kept by the issuing bank. |
| ERR CC SECURITY ID DOES NOT MATCH | 12678 | Security ID provided at entry time doesnt match the above |
| ERR CC SECURITY ID NOT PROCESSED BY CREDIT CARD VENDOR | 12682 | the data is not supported by the CC vendor (ie: brand) Ie: TP, JCB etc. |
| ERR CREDIT CARD ISSUER DOES NOT SUPPORT SECURITY ID | 12683 | Issuing bank system is unable to cope with CC sec ID data |
| ERR CREDIT CARD ISSUER STATES SECURITY ID IS ON THE CARD | 12684 | when CV is entered with M as missing (client states theres no CC sec id on his card) but bank responds there IS one present. |
This example creates a payment for american express credit cards.
See "Error Messages" section.
create a payment for american express credit cards.
All standard error messages are outlined in the section, "Error Messages".
The security Id may be conveyed to the CC database.A dedicated field, securityIdResponse, is sent back in the reply.
See "Error Messages" section.
Further to the VbV (Verified by Visa) project, new data field may becarried into the CC message when the request for authorization is sent tothe CC Company (onto the VISANET link). This is applicable to VISA cards(vendor code VI) and MASTERCARD group (vendor codes: BZ, CA, EC and XS).
This occurs when an authentication process (client identity verification)occurred upstream the authorization process (card creditworthiness check).This authentication process occurs in the case the cardholder is subscribinginto the VbV program through an enrolled issuing bank.It enables the bank to verify that the cardholder is properlyauthenticated when purchasing goods over the Net.
The authentication fields available are listed as such:
See "Error Messages" section.
Create a master card payment with address verification information.
All standard error messages are outlined in the section, "Error Messages".
Create a visa card payment with country code override option.
All standard error messages are outlined in the section, "Error Messages".
Create a visa card payment without address information.
All standard error messages are outlined in the section, "Error Messages".
The Validate Credit Card function requests Credit card validation from the preferred Credit card company, in return the Credit card company is sending back an approval code to validate the request made in the Passenger Name Record (PNR).
The Powered Ticket, Validate Credit Card function allows forthe validation of an accepted Credit Card
Here is a list of the Credit Cards accepted by the System:
It should be noted that not all airlines accept all credit cards listed as aform of payment. Also it should be noted that even though an airline may well accept a specific credit card as a form of payment, it might not allow automatedapproval processing in the Amadeus system.
Not applicable
A pre-requisite to use the Validate Credit Card function is to validate the card.Data requirements include such items as: Credit Card number, expiry date,vendor code and agent type.
The validation process can be stopped for one of the following errors:The Credit Card has expired, thereis an invalid account number and or the form of payment is invalid.
Depending on the flavor of the API that is used, each query will follow a givenstructure. The queries for the function operations are clearly explained with dataelement examples in a generic table view that can be adapted to the specific flavorof the API in use.It is important to note that the examples in each chapter are only illustrationsand are meant to provide the basis for a better understanding on which fields aremandatory for basic operation utilization. It is not a full explanation of everyfield that can be utilised for the operation, but rather a guideline to its use.
There is only one mandatory field in the queryand that is the authorization process type, such as FP.
The following code sets may be utilised when building a query for this function:
| Code | Company Identification |
|---|---|
| AB | Australian Bank |
| AU | Carte Aurrore |
| AX | American Express |
| BC | Bank Card of Japan |
| BH | Bank of Hawaii |
| CA | Mastercard |
| CB | Carte Blanche |
| CS | Citizens amp; Southern National Bank |
| CU | Connecticut Bank/Trust Co |
| CX | City National Bank Coice Card |
| DC | Diners Club/American Torch Club/Sun Diners Club |
| DS | Discover Card |
| EC | Eurocard |
| FH | Federation Nationale de l'industrie Hoteliere |
| ID | Comites |
| IK | Interbank |
| JC | Japan Credit Bureau |
| MC | Million Credit Service |
| MD | Diamond Credit |
| MT | AEmpire Card |
| OK | Finnish domestic credit card |
| OT | OTB Card |
| RA | Raptim-France |
| SC | Shoppers Charge |
| SR | Select Credit |
| TC | Trust Card |
| TP | Universal Air Traval Plan (Air Traval Card,Airplus,PassAge) |
| UD | Union Credit Bankcard New Zealand |
| VI | Visa International Discover Card |
| WB | Walker BankCard |
| XS | Access |
| Code | Form Of Payment Identification |
|---|---|
| CC | Credit Card |
| Code | Response Type, Coded |
|---|---|
| U | Descriptive Billing data updated |
| Code | Processing Status Code |
|---|---|
| P | OK processed. No data follows |
| Code | Processing Indicator, Coded |
|---|---|
| B | Credit Card authorization based on both PNR and MCO Form of Payment |
| FP | Credit Card authorization based on PNR Form of Payment |
| MCO | Credit Card authorization based on MCO form of payment |
The authorization code (also known as approval code) can vary from 1 to 6characters and is returned in the PNR (Passenger Name Record).
In this example the data for the attribute is sent as well as the approvalCode for thevalidation made and the PNR is updated with the approval code, which could be anything upto and including 6 characters.This information needs tobe 'captured' and used to fill up the ValidateDescBillData function fields.
On processing a Validate Credit Card request there are only two outcomes possible,either a rejection or an authorization for the transaction.If the request was not successful, the response will be an appropriate error message.
In this example the data for the attribute is sent as well as the approvalCode for the validation made and
the PNR is updated with the approval code, which could be anything upto and including 6 characters. This
information needs to be 'captured' and used to fill up the
ValidateDescBillData
function fields.
See "Error Messages" section.
Validate credit card using a generic credit card.
See the section, "Error Messages".
Further to the VbV (Verified by Visa) project, new data field may be carried into the CC message when the request for authorization is sent to the CC Company (onto the VISANET link). This is applicable to VISA cards (vendor code VI) andMASTERCARD group (vendor codes: BZ, CA, EC and XS).
This occurs when an authentication process (client identity verification)occurred upstream the authorization process (card creditworthiness check).This authentication process occurs in the case the cardholder is subscribinginto the VbV program through an enrolled issuing bank.It enables the bank to verify that the cardholder is properlyauthenticated when purchasing goods over the Net.That is the reason why, these authentication data may only be availablein the transaction for Amadeus clients using the Planitgo application.
The authentication fields available are listed as such:
See "Error Messages" section.
This function provides Amadeus Customers with an automatic way to create TSM-P.
In the TSM-P, the system automatically stores information obtained from the pricing engine during a previous Service pricing transaction.
There are as many TSM-P created as there are different passengers.
The function CreateTSMFromPricing allows the following operation:
Create TSM
A pricing transaction must have been performed before.
At least one name and one service must exist in the PNR.
The query contains the references to the different TSM that have to be created. These references have been returned by a previous pricing transaction.
The received reply (except error messages) contains TSM number and Passenger association.
The reply contains the reference of the TSM created with its passenger association.
Data:
TSM Reference (IRV): the reference to the created TSM (tattoo number and identification number)
Pax Information (REF): the reference of the passengers that are associated to the TSM
CM00001 - Unable to process
Process error - normally it shouldn't be related with data from the request.
CM00005 - Check segment number
‚‚‚Â A segment with the TATTOO number specified in the REF segment is not present in the PNR
CM00258 - Function not supported
Request a functionality not yet implemented
CM00339 - Need Name
The PNR does not contain any names.
CM00357 - Link down
A problem of communication between the different systems occurs.
CM00477 - Invalid format
Data specified in the request is not valid, although is OK from the message definition
Examples: recommendation number is not digit.
CM01908 - Check passenger number
A segment with the TATTOO number specified in the REF segment is not present in the PNR
CM01959 - Need PNR.
A request has been made without a retrieved/newly created PNR.
CM01966 - Need itinerary
There is no itinerary in the PNR.‚‚‚Â
Contains ET - Electronic Ticket - related functions:
This function allows to request airport controlof ET flight coupons from a carrier.
This function allows requesting the transfer of control of ET flight coupons to a carrier.It is also known as Redirect Airport Control. The carrier that the control is pushed to is knownas the new operating carrier.
This function can be used in interline scenarii.
All targeted flight coupons shall belong to the same ET.
This function cannot be used in ground handling scenarii.
The user should be familiar with ET functionality and can refer tothe IATA Passenger ServicesConference Resolutions Manual Resolution 722f (airline) and Resolution 722g (neutral) for moredetails.
An ET record shall be attached to the AAA
The involuntary indicator can be part of the query.
The query shall contain the ET flight coupons airport control is requested for.
The query shall contain the ET flight coupons that airport control is being pushedtogether with the new operating carrier.
The reply acknowledges or rejects the Get Airport Control request or Push Airport Control request.
For valid transactions, a message is sent to the ET database of the airline the requesting officebelongs to, to request the ET update. If the ET database reply indicates the request was processedsuccessfully, the system returns:
| 09173 | OK ETKT RECORD UPDATED |
The following example illustrates a successful push airport control.
The get airport control request is only valid after an ET display request.If no ET record is attached to the AAA, the system replies:
| 07108 | NO ET DETAILED RECORD PRESENT |
The ET flight coupon(s) specified in the request must exist in the ET.The system rejects a wrong coupon specification with the following message:
| 10592 | INVALID COUPON NUMBER |
If the coupon status is not "O" nor "A" nor "N", the system rejects the transactionwith the following message:
| 05486 | INVALID TICKET/COUPON STATUS |
For valid transactions, a message is sent to the ET database of the airlinethe requesting office belongs to, to request the ET update.
If the ET database reply indicates the request is rejected for validating carrier YY,the system returns the error message contained in the ET database reply:
YY ETKT: ERROR MESSAGE
This example illustrates a get airport control request for the first coupon of an AA ET.
AA may reject the request.
This example illustrates the redirect airport control of the second coupon of an AY ET tothe new operating carrier IB. Involuntary Reroute indicator is set in the query.
AY may not support the redirect airport control message.