> ## Documentation Index > Fetch the complete documentation index at: https://developers.pcibooking.net/llms.txt > Use this file to discover all available pages before exploring further. # Working with Third Parties > How PCI Booking sits in the message path between you and a third party, so card data is swapped for tokens on the way in and tokens are swapped for card data on the way out. 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](/account-setup/target-profiles) 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. | | You call the third party | The third party calls you | | - | - | - | | **The card arrives at your system** | [Tokenization on Response](/capture-cards/tokenization-on-response): you request data, and the card in the response is tokenized. | [Tokenization on Request](/capture-cards/tokenization-on-request): the third party sends you a card, and it is tokenized before it reaches you. | | **The card leaves your system** | [Token Replacement in Request](/use-tokens/token-replacement-in-request): you send a request with a token, and the card is inserted before it reaches the third party. | [Token Replacement in Response](/use-tokens/token-replacement-in-response): the third party calls you, you answer with a token, and the card is inserted in your answer. | 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](/use-tokens/universal-payment-gateway). Full workflow: [Process OTA and Channel Manager Payments](/use-cases/third-party-to-gateway). ### 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](/use-cases/capture-and-send-to-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](mailto:support@pcibooking.net) and the team builds it for you. See [Target Profiles](/account-setup/target-profiles). * **Universal profiles for common third parties.** PCI Booking maintains ready-made profiles for some third parties, see [Universal profiles](#universal-profiles) below. * **A gateway address, if third parties call you.** The support team sets it up, see [Tokenization on Request](/capture-cards/tokenization-on-request#setting-up-a-gateway-endpoint). * **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](/reference/outbound-ips). ### Universal profiles Universal profiles use a separate endpoint, [Tokenize on Response Using Preset Profiles](/api-reference/tokenize-cards/tokenize-on-response-using-preset-profiles), where the target URL comes from the profile. Get the current list from [Get Tokenization Profiles](/api-reference/tokenize-cards/get-tokenization-profiles). Universal profiles work for tokenization on response only. When you are ready to go live, see [Moving Configuration to Production](/getting-started/moving-to-production). ## Related * [How PCI Booking Works](/concepts/how-pci-booking-works). The overall model. * [Capture Cards Overview](/capture-cards/overview). All ways to get a card into PCI Booking. * [Use Tokens Overview](/use-tokens/overview). All ways to use a stored token. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.