NAV Navbar
cURL
  • Introduction
  • Usage
  • Channels
  • Errors

    • Introduction

    What is the SysPay PCI Proxy?

    Fetching or being pushed booking information that contain card data on your system makes PCI compliance complicated. It extends the scope and increases the number of checks and security controls you have to put in place to meet compliance.

    To avoid card data to reach your system, we have developed a man-in-the-middle solution which will take care of extracting card data from the messages exchanged with the various channels you are dealing with, and replace them with tokens that you will organically be able to use with our Hospitality API.

    PCI Proxy

    The SysPay's PCI Proxy supports both directions. You can either use it to fetch information from your channels, or to receive notifications from them.

    In both cases, the actual card number of the original message will be replaced by a token id that you can use later on with our Hospitality API to create tokens/bookings as usual. The cvc and the card expiration date will be replaced by dummy values. Only the cardholder name will not be changed.

    No change will be required to your current Hospitality API implementation as we will automatically detect that the card number you are passing is a PCI Proxy token, and it will be substituted accordingly by the actual card information before being processed.

    The OUT flow

    That allows you to call remote webservices via SysPay. We will forward your request to the actual end point, extract the card data from the response (if any), replace them with PAN lookalike token ids, and provide you with the sanitized response.

    OUT flow

    The IN flow

    That allows you to receive notifications from remote systems via SysPay. In this case you will use a specific SysPay URL per channel you want us to proxy (provided by us). When we receive a notification from one of these channels, we will extract the card data, replace them with PAN lookalike token ids and forward you the sanitized notification on the URL of your choice.

    IN flow

    Usage

    OUT flow

    Sample request

    $ curl -XGET \
-H 'X-PCI-Proxy-Client-Id: xxxx' \
-H 'X-PCI-Proxy-Basic-Authentication: xxxx' \
-H 'X-PCI-Proxy-Forward-To: https://api.channel.com/bookings?since=1503402189' \
https://app.syspay.com/proxy/out

    To issue requests through the SysPay PCI Proxy, you will need:

    We will authenticate your calls and know about the final endpoint using the following HTTP headers:

    Header Value
    X-PCI-Proxy-Client-Id Your PCI Proxy user id
    X-PCI-Proxy-Basic-Authentication Your PCI Proxy password
    X-PCI-Proxy-Forward-To The endpoint to forward the request to

    If the authentication was successful, we will forward your request (including any parameter or custom header that you provided) to the given endpoint. Any card data received in the response will be tokenized, assuming this is for a supported channel and message type. Other messages will be passed without any change.

    We will also return the HTTP headers and status code as we have received it from the remote. Errors coming from the PCI Proxy will be returned using specific HTTP headers.

    The response will include an extra X-PCI-Proxy-Token-Count header that will contain the number of cards that have been tokenized in the proxied message.

    IN flow

    You will receive a specific URL to receive notifications for each of the channels you would like to go through us.

    This is actually the only change you are required to do to your setup.

    Additionaly, the forwarded request will include an extra X-PCI-Proxy-Token-Count header that will contain the number of cards that have been tokenized in the forwarded message.

    Integration with the SysPay API

    There is no extra work to do to integrate our PCI Proxy with our Hospitality API. The sanitized message will still contain the cards PAN, expiration date, cvc and holder name and can be passed as it to our webservices. They will be automatically recognized and substituted with the actual card data tokenized during the proxy request.

    Restrictions

    The following restrictions apply to both flows:

    Channels

    The channels we currently support are:

    Channel Flow Notes
    Booking.com OUT B_XML Legacy XML
    Expedia OUT QuickConnect Booking Retrieval API
    TripAdvisor IN Instant Booking API

    Errors

    If something went wrong while proxying your request, the error will be reported using the following headers:

    Header Description
    X-PCI-Proxy-Error-Code Error code (see table below)
    X-PCI-Proxy-Error-Message Error message

    Error codes

    The following error codes could be returned:

    Code Description Applies to
    100000 We couldn't fetch the response from the remote endpoint, for a reason not listed below. OUT/IN
    100001 The remote certificate is invalid, expired or couldn't be verified OUT/IN
    100002 The remote hostname could not be resolved OUT/IN
    100003 The connection to the remote has been refused OUT/IN
    100004 The connection to the remote timed out OUT/IN
    200000 The X-PCI-Proxy-Forward-To header is missing OUT
    200001 The proxy integration could not be found for the given URL IN
    200002 The remote endpoint is not over HTTPS OUT/IN
    300000 An error occured during the tokenization process OUT/IN
    cURL