Security and Encryption

Because the data that is transmitted to and from our system contains very sensitive information, we take great precautions to ensure it is processed securely. Travelport is ISO certified. In addition to securely transmitting and storing the standard name, address, phone, and email address data elements, Travelport also communicates and stores credit card information. We have in place the following technology and processes to protect that sensitive information, as explained below.

PCI Compliance and PII

Payment Card Industry (PCI) compliance demands that credit card data be protected to greater extremes than typical personal information. As a result we have incorporated secure encrypted communication methods, as well as high level of encryption when we store the information in our system. In our production environment, HTTPS must be used for most transactions to secure the data.

The following forms of payment are encrypted in our system:

The following PII (Personally Identifiable Information) is encrypted in our system:

Travelport's compliance letter can be viewed here. To request more information, please contact your account manager or customer support representative.

Data Masking

All credit card numbers are masked with asterisks (*), except for the last four digits whenever they are returned from Universal API. All transactions that return the CreditCard or FormOfPayment element are implemented in this manner, with some exceptions based on the provider-mandated settings..

Because of the masking, returned data cannot be directly used in another request because the numbers are replaced in our response message. The CreditCard or FormOfPayment must be referenced in all subsequent requests. Each request that has this limitation allows the reference, or a completely new element, to be sent in subsequent requests. For example, AirExchangeTicketingReq allows the option of using the new element (FormOfPayment) or the reference (FormOfPaymentRef).

This action cannot be turned off globally because it is a PCI requirement. However, pursuant to PCI standards, it can be turned off for discrete individuals that have proper authority to view the more sensitive information. This authority includes managers or supervisors, and people responsible for managing credit card processing and fraud prevention.

Using HTTPS

Most SOAP clients, both commercial and open-source, support secure communications via the HTTPS protocol. A client application does not need to adapt in any custom way other than the standard mechanisms that HTTPS demands.

Data Masking in PNRs

Generally, an FOP is associated to a passenger name record (PNR). When issuing Ticket, the PNRs FOP is used to issue a ticket. While issuing ticket, it is possible to ignore the PNR’s FOP and introduce a new FOP. This new FOP will not be saved in the PNR. This override FOP can also be done through Universal API.

Data Masking in the Provider Response

In general, if the provider returns the Credit Card Number unmasked to Universal API, Universal API returns it in the response without masking.

For example, this sample shows the Credit Card returned in Universal API response where the individual setting is configured to return an unmasked Credit Card Number:

Request

<univ:AirCreateReservationReq…><com:FormOfPayment Key="PDz8y7xu4hGdeB/wYIhwmw==" Type="Credit"> <com:CreditCard Type="CA" Number="5407123456781115" CVV="737" ExpDate="2091-12" Name="JON DOE" Key="7AAADaaaRX99c9ApaAaaaA==">

Response

<universal:AirCreateReservationRsp…> <common_v41_0:FormOfPayment <common_v50_0:CreditCard Type="CA" Number="5407123456781115" ExpDate="2091-12" Name="JON DOE">

The default setting is to return Credit Card FOP data masked. Universal API returns the masked value in the Universal API response. For example:

Request

<AirCreateReservationReq…> <com:FormOfPayment Key="IAm8y7aw3sOmeB/wYIhwmw==" Type="Credit"> <com:CreditCard Type="CA" Number="5407123456781115" CVV="737" ExpDate="2091-12" Name=" JON DOE " Key="5YOUAreaWE23s8OmeToohQ==">

Response

<AirCreateReservationRsp…> <common_v41_0:FormOfPayment Key="PDz8y7xu4hGdeB/wYIhwmw==" Type="Credit" Reusable="true" ProfileKey="5YOUAreaWE23s8OmeToohQ==" ElStat="A"> <common_v50_0:CreditCard Type="CA" Number="************1115" ExpDate="2091-12" Name="JON DOE">

Data Masking with General and Accounting Remarks

Apart from the FOP field, if the Credit Card number is added in the General Remark or Accounting Remark elements, and the provider returns it without masking, Universal API does not mask the information. For example:

<common_v50_0:GeneralRemark Key="iamawlEsOMEANDUl2ARETOO==" Category="A" TypeInGds="Alpha" ProviderReservationInfoRef="youalArE0AWESom2ETOOME=="> <common_v50_0:RemarkData>FOP-F-AX379412345678910/D0622</common_v50_0:RemarkData> </common_v50_0:GeneralRemark>

Conclusion

  1. If the Credit Card number is returned by provider unmasked, Universal API will return the data unmasked.
  2. The configuration default is set to mask the credit card on the provider system. However, with special permission for specific PCCs, it can return unmasked credit card data.
  3. For fields other than FormOfPayment or FormOfPaymentRef and CreditCard elements, if the Credit Card number is present (e.g., GeneralRemark or RemarkData), Universal API does not mask it, and returns the credit card data "as is."