Case Study – Travel
This client required the ability to collect and store credit cards securely from their booking page until required for payment. The transaction process starts with the first 2 requests being sent to the airline company to determine if tickets were available and then the 3rd transaction needs to be sent securely with the credit card number to the airline. The first 2 transactions provide a booking number which is then sent along with the credit card in the payment request over to the airline for processing. Once the booking request has been completed the travel company then needs the ability to charge the same card for 2 additional payments 1 payment to the insurance company and the last transaction was sent to the payment gateway to process the surcharge.
HostedPCI first needed to determine the correct collection method for this client, we were able to identify this quickly since all transactions took place through the travel company’s webpage. It was decided that the collection solution required was the iFrame. The reason for this is that the iFrame can be embedded into the client’s checkout page allowing them to remain in control of the entire transaction processes without being required to handle the credit card internally. The HostedPCI iFrame tokenizes the credit card directly from the browser before the customer details including the credit card. The client is provided with an independent and durable token which can be used with any third-party or supported gateways as many times as required.
The first transaction that is processed through HostedPCI is the booking transaction, unlike a regular sale transaction the credit card is not actually processed by the travel company. The transaction is processed by the airline company which confirms the booking, for this reason, the API action that is required for this transaction is our XML Message Dispatch. This transaction type allows the client to construct the API request according to the airline’s requirements to provide the customer and transaction details to the airline for processing. Since the travel company only has the token, the client will send the API request to HostedPCI with the token, and HostedPCI will replace the token with the credit card before passing the message on to the airline.
“The transaction is Processed by the airline company which confirms the booking, for this reason, the API action that is required for this trasaction is our XML Message Dispatch. This transaction type allows the client to construct the API request according to the airline’s requirements to provide the customer and transaction details to the airline for processing.”
The insurance transaction will follow the same path as the booking transaction however in this case the third-party has changed and therefore may require a different request structure. Like the airline transaction, the client will compile the appropriate request with the customer details including the token and will send the transaction to HostedPCI for the insurance company to charge the insurance fee to the client.
For the surcharge transaction, this is completed against the selected payment gateway, in this case, the travel company’s gateway was Moneris. The structure of the payment request is different from the request for XML Dispatch, unlike the 3rd-party request which is structured by the client the gateway request is structured using specific parameters provided by HostedPCI to make sending the Sale request simple.
By utilizing HostedPCI for their PCI DSS compliance this travel company was able to reduce their PCI scope by removing the entire collecting, storing and exchanging process out of their environment and over to a secure 3rd party proxy, which reduced their PCI scope from an SAQ type D which is roughly 400 questions and lowering it to an SAQ type A which is only 11 questions.