Skip to main content
Many travel systems exchange cards with other systems: an OTA sends a reservation to a hotel system, a channel manager forwards it to a property management system, a hotel platform sends a card to its payment gateway. PCI Booking can sit in the message path of any of these exchanges. Card data is replaced with a token on the way into your systems, and the token is replaced with card data on the way out. Your systems only ever see tokens.

​
How It Works

The messages you already exchange with third parties keep their format. You change only where they are sent: through PCI Booking instead of directly. PCI Booking reads each message, finds the card data using a target profile that describes the message format, and does one of two things:
  • On the way in, it replaces the card data with a token, so your systems receive the token.
  • On the way out, it replaces your token with the real card data, so the third party receives the card.

​
Pick the Method by Who Starts the Call

Four methods cover every direction. The one you use depends on whether the card is arriving or leaving, and on who sends the request. When you call the third party, you send the request through PCI Booking’s relay. When the third party calls you, it sends the request to a gateway address that PCI Booking sets up for you, which then forwards it to your system.

​
Examples

​
A hotel platform receives OTA cards and charges them

An OTA pushes reservations with the guest’s card to your platform (Tokenization on Request), or your platform pulls reservations from the OTA (Tokenization on Response). You store the tokens and charge them through the Universal Payment Gateway. Full workflow: Process OTA and Channel Manager Payments.

​
An OTA sends a guest’s card to a hotel

You capture the guest’s card as a token, then deliver it to each hotel in the way that hotel can receive it, for example by pushing the reservation to the hotel’s system through the relay (Token Replacement in Request). Full workflow: Send a Guest’s Card to a Hotel.

​
A channel manager forwards OTA cards to a property management system

Your platform sits between OTAs and property management systems and should never see card data.
  1. The OTA pushes a reservation to your gateway address. The card is tokenized and your platform receives the reservation with a token (Tokenization on Request).
  2. You store the token with the reservation.
  3. You push the reservation to the property management system through the relay. The token is replaced with the card on the way (Token Replacement in Request).
If the property management system pulls reservations from you instead, use Token Replacement in Response for step 3.

​
What You Set Up

  • A target profile for each message format. It tells PCI Booking where the card data is in the message. You can build one in the portal, or send a sample message to support@pcibooking.net and the team builds it for you. See Target Profiles.
  • Universal profiles for common third parties. PCI Booking maintains ready-made profiles for some third parties, see Universal profiles below.
  • A gateway address, if third parties call you. The support team sets it up, see Tokenization on Request.
  • Allowlisting, if third parties restrict callers. When PCI Booking calls a third party on your behalf, the call comes from PCI Booking’s addresses. See Outbound IP Addresses.

​
Universal profiles

Universal profiles use a separate endpoint, Tokenize on Response Using Preset Profiles, where the target URL comes from the profile. Get the current list from Get Tokenization Profiles. Universal profiles work for tokenization on response only. When you are ready to go live, see Moving Configuration to Production.