Payment Card Authorization

The Payment Card Authorization request verifies whether a cardholder's payment card is authorized for sufficient funds and approved for future settlement.

When cardholder address objects are included in the AUTH request, an address verification takes place at the same time. If an address verification is not performed during authorization, you can use the Address Verification Service to send a standalone request later.

The payment transaction type "AUTH" is used to obtain a payment card authorization for a specific card number and value against a specified merchant vendor. Note that merchant ID is not the payment card vendor but rather the transaction's merchant of record; for example, BA for a ticket issued on British Airways.

A successful authorization request generates a response indicating the status of the transaction.

Optionally, the Payment Card Authorization request can include agency-generated 3-D secure authentication. See Payment Card Authorization with 3DS for more information and specific examples.

Contact your Travelport representative for endpoints for the Pay APIs.

In this topic:

• Payment Card Authorization Request
• Additional Notes
• Payment Card Authorization Response
• Additional Notes

Endpoints

Payment Card Authorization Request

To request a credit card authorization transaction, send PaymentCardAuthorizationRequest with PaymentTransaction@authorizationType: "AUTH".

The following table details the objects in the request. Be sure to see the Additional Notes after this table.

Object	Required	Optional /Conditional	Notes/Example
PaymentCardAuthorizationRequest	Top level object for request.
PaymentCardAuthorizationQueryRequest	Top level object for request.
PaymentCardRequest
	airlineMerchantCode		AA If object is not sent, error 252
	expireDate		MMYY If object is not sent, error 254
		agentSignOn	ABC123BZ If object is not sent, error 254
	localDateTime		YYYY-MM-DDTHH:MM:SS If object is not sent, error 258
	paymentCardCode		CA, VI, DS, AX, DC, TP, JC. If object is not sent, error 268
	primaryAccountNumber		4444333322221111 If object is not sent, error 260 Minimum 6 characters, maximum 19
		extendedPaymentInstallments	99 If format is invalid, error 211
		paymentCardSecurityCode	123 If format is invalid, error 255
		uCAFIndicator	2 If usage is invalid, error 256
		eCI cAVV xID	See Payment Card Authorization with 3DS for additional information.
	CurrencyAmount: value code minorUnit decimal		If object missing, error 261 200.56 USD
PromotionCode
		promotionCode	12345678 If format is invalid, error 264
AgencyPCCDetail		StateProv
		PostalCode
TravelInfoAir		Note: All TravelInfoAir key value pairs are conditional.
		departureDate	YYYY-MM-DD
		numberOfTravelers	4
TravelInfoAir.Traveler.PersonName		Given	John
		Middle	E
		Surname	Doe
TravelInfoAir.LocatorCode		LocatorCode value	DEMCBA
		fareBasisCode	First fare basis code of the itinerary. YEE1Y
		AirlineCodes	All airline codes for the entire itinerary. AA AC UA
		AirportCodes	All airport codes for the entire itinerary. LAX YVR YMQ JFK
Cardholder
		CardholderName	Name on the card; simple string. MR BOB CITIZEN
		Address_Line	123 WEST STREET
		PostalCode	1234
		IP4Address	123.123.123.123
		dob	YYYY-MM-DD
		Gender	Male
		Given	John
		Middle	E
		Surname	Doe
		City	Denver
		StateProv value	CO
		Country value	US
		Telephone role	Mobile
		phoneNumber	5551212
		Email value	happy.customer@travelport.com

Additional Notes

Note 1: Rules for AddressDetail

If AVS data is sent, address verification will be processed along with authorization

Note 2: Rules for TravelInfoAir (Itinerary data)

• If only the GDS RLOC is sent, Travelport retrieves the applicable reservation and uses the current itinerary data stored in the host. (If any itinerary changes have not been end transacted they will not be reflected in the itinerary data.)
• If the GDS RLOC is sent AND itinerary data is sent, Travelport uses the itinerary data sent in the API request. Travelport will not retrieve the GDS record locator to compare the request itinerary and GDS itinerary.
• If itinerary data is sent without GDS record locator, Travelport uses the itinerary data in the AUTH request.
• If no itinerary data and no GDS record locator is sent, Travelport will not process the request.
• If the GDS record locator that is sent in the AUTH request is invalid or nonretrievable, Travelport will continue the AUTH request without the itinerary data.

Note 3: FareBasis

Only one occurrence of the fare basis may be sent. This should be the first fare basis for the passenger the authorization is being requested for.

Note 4: PersonName

PersonName refers to the traveler not the cardholder. Only one occurrence of personName may be sent. When multiple passengers exist for the authorization request, send only the first passenger.

Note 5: Cardholder Fields

Additional cardholder fields will be implemented to support fraud screening in a later release.

Note 6: 3-D Secure Fields

• Individual card scheme rules may apply.
• If 3-D secure data fields are provided by the subscriber the ECI is mandatory.

Payment Card Authorization Response

The response returns the objects detailed below.

Object	Description
PaymentCardAuthorizationResponse	Top level object for response. Key value pair:  transactionId: Internal identifier for the transaction.
PaymentCardAuthorization	Provides confirmation details in the following key value pairs: completionCode: Code 000 is the OK response. See PaymentCard Response Codes for other codes. approvalCode: TBD PrimaryAccountNumber: The credit card number sent in the request.