Skip to main content
Many travel systems pass cards to partners: an OTA sends a reservation to a hotel, a channel manager forwards it to a property management system, a platform hands a card to a business partner. PCI Booking gives you five ways to do this. This page compares them and outlines the flow for each, with links to the pages that hold the detail.

​
Choose an Option

The first question is whether your partner is also a PCI Booking customer. If it is, you can give it the token itself. If it is not, you can send it the card data or show it the card.

​
When You Need a CVV Policy

A CVV retention policy matters only when a CVV is stored on the token and the partner needs it. If the token has no CVV, or the partner can work without it, there is nothing to set. When the partner does need the CVV, two rules decide the option:
  • A policy is fixed 60 minutes after the CVV is stored. Only the token’s owner can set it within that window. After that, nobody can change it, not you and not PCI Booking.
  • Each use draws from the quota of a destination. The partner gets the CVV only if the policy has a destination for its use, for example Upg for a charge, HostName for a relay or OtpCardView for a card view, with quota left. See Destination Types.
So decide what the partner will do with the CVV before the window closes. If the existing policy does not fit and the window has closed, the only way to get a policy that fits is a new token: duplicate, then transfer.

​
Share the Token

You keep the token and give the partner access to it. The partner can use the token as if it were its own, but it cannot delete it. When to use it. The partner needs to act on the card for a limited time, for example a hotel charging a no-show, and you want to stay in control of the card. Benefits
  • No card data leaves PCI Booking, and no new token is created.
  • You can remove the partner’s access at any time.
  • The partner can share the token onward with its own partners. You can see who shared it with whom.
Implications
  • CVV. Your policy governs every use, including the partner’s. Only you can set it, so include the partner’s uses when you set the policy. The partner’s uses draw from the same quotas as yours: if you and the partner both charge through the Universal Payment Gateway, both charges count against the one Upg quota.
  • Billing. Sharing the token and removing access are free. For later actions, the account billed depends on the action, not on who performs it. See Billing on a Shared Token.
Flow
  1. Tokenize the card, with any capture method.
  2. If the partner needs the CVV, set the CVV retention policy within 60 minutes, with a destination for each of the partner’s uses.
  3. Associate the token with the partner: Associate with Customer.
  4. Send the partner the token URI. It is not sensitive data.
  5. When the partner no longer needs access: Disassociate from Customer.
Full walkthrough: Share a Card Token Between Merchants. Permissions detail: Third-Party Permissions.

​
Transfer Ownership

You hand the token to the partner. The partner becomes its owner and you lose access to it. When to use it. The card now belongs to the partner’s business, and you have no further use for it. For example, a reservation moves to another company for good. Benefits
  • The token keeps its URI, so nothing has to be re-captured or re-sent.
  • The partner becomes responsible for the token from then on, including storage and deletion.
  • The existing CVV policy continues to apply. Nothing needs to be set again.
Implications
  • Access. You lose access to the token, unless the partner shares it back with you. You cannot undo the transfer yourself.
  • CVV. The policy stays exactly as it was. The partner cannot change it once 60 minutes have passed since the CVV was stored. If the policy does not cover what the partner needs, for example it has no quota left for charges, use duplicate, then transfer instead.
  • Billing. The transfer is billed to both sides: a transfer fee to you and a receiving fee to the partner. From then on, the partner is the owner and pays the storage, and the actions billed to the owner in the table above.
Flow
  1. Confirm that the partner’s PCI Booking user ID is correct. The transfer is permanent.
  2. Transfer the token: Transfer Ownership.
  3. Send the partner the token URI.

​
Duplicate, Then Transfer

You create a copy of the card and hand the copy to the partner. You keep the original. You and the partner end up with two independent tokens. When to use it. You both need the card, each on your own terms. Or the partner needs the CVV in a way the original token’s policy does not allow. Benefits
  • Each side owns, controls and pays for its own token.
  • The copy gets a new CVV policy that can be set for the partner’s needs.
  • Your original token, and its policy, are untouched.
Implications
  • CVV. The original CVV is never copied. If the partner needs the CVV, you must provide it when you duplicate, or have the cardholder enter it with the CVV Capture Form. The copy gets your account-wide default policy, not the partner’s. To set a different policy, set it within 60 minutes of creating the copy, or transfer the copy within that time so that the partner can set it.
  • Billing. The duplicate is billed to you as a new tokenization. The transfer is billed as above: a transfer fee to you and a receiving fee to the partner. From then on, you pay for the original and the partner pays for the copy.
Flow
  1. Create the copy with the CVV: Duplicate a Token.
  2. Set the CVV policy for the partner’s uses within 60 minutes: Set CVV Retention Policy. Or skip this step and let the partner set it, if you transfer within the 60 minutes.
  3. Transfer the copy: Transfer Ownership.
  4. Send the partner the URI of the copy.

​
Relay the Card

PCI Booking sits in the message path between you and the partner. The messages you already exchange keep their format: you only change where they are sent. 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. When to use it. The partner is not a PCI Booking customer, or it needs the card in its own systems, for example a property management system that receives reservations through its API. Benefits
  • Works with any partner that has an endpoint. The partner does not need a PCI Booking account.
  • Your systems only ever see tokens, in both directions.
Implications
  • The partner receives the real card. Once the card leaves PCI Booking, it is in the partner’s systems and in its PCI DSS scope.
  • CVV. The CVV is included only if your policy has quota for the partner’s host (HostName), or for the partner’s IP address when the partner calls you (IpAddress). Each relay with the CVV uses one. If there is no quota, the rest of the card is still sent, without the CVV. If the partner is a PCI Booking customer and tokenizes what it receives, its own policy applies to its new token.
  • Billing. Each token replacement is billed to the token’s owner. If the partner tokenizes what it receives, the partner pays for its own tokenization and storage.
Flow PCI Booking reads each message with a target profile that describes the message format. The method 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.

​
Show the Card

The partner views the card on a PCI Booking page. Nothing is sent to the partner’s systems. When to use it. The partner only needs to read the card, for example a hotel that takes payment on its own terminal and has no system that can receive cards. Benefits
  • No integration on the partner’s side. With Card Display with OTP, the partner needs only an email address and a phone.
  • The card is never stored in the partner’s systems.
Implications
  • Manual. A person reads the card and keys it in, so this suits low volumes.
  • CVV. The CVV is shown only if your policy allows that view, OtpCardView for Card Display with OTP. Each view that shows the CVV uses one.
  • Billing. Card Display with OTP is billed to the account that requests the view. Card Display in your own portal is billed to the token’s owner.
Flow
  1. Request the view: Card Display with OTP, or embed Card Display in a portal the partner logs in to.
  2. The partner views the card on PCI Booking’s page.
Full walkthrough, including how to pick a method per hotel: Send a Guest’s Card to a Hotel.