Send a Guest's Card to a Hotel

This workflow is for OTAs, booking engines and other travel companies that receive a guest’s card and must pass it to a hotel. You work with a token from start to finish. PCI Booking delivers the card to the hotel, so the card data does not reach your systems.

​

Step 1: Get the Token

You get the token in one of two ways:

• Capture the card from the guest. Use the Hosted Card Entry Form on your booking page, or send the guest a Card By Link request by email or SMS.
• Receive the card from a third party. If an OTA or channel manager sends you the card, use Tokenization on Response when you call them, or Tokenization on Request when they call you.

The result is a card token (a URI pointing to the stored card details in PCI Booking).

​

Step 2: Choose How Each Hotel Receives the Card

You can use a different method for each hotel.

​

Step 3: Set Up the Delivery Method

​

Card Display with OTP

There is nothing to set up on your side or on the hotel’s side.

1. Call the Card Display OTP endpoint with the card token and the hotel contact’s email, phone number and name.
2. PCI Booking sends the hotel contact an email with a secure link.
3. The hotel contact opens the link and verifies their phone number with a code sent by SMS or voice call.
4. The card details are shown on PCI Booking’s hosted page. The link is valid for the TtlMinutes you set (1-30, default 10) and works once.

See Card Display with OTP for full details.

​

Card Display (iframe in your portal)

If hotels log in to your own portal, show the card details in a secure iframe in that portal.

• Generate a Card Display Form link for the token.
• Embed the iframe in your portal. The card details render inside PCI Booking’s secure domain, so card data never touches your servers.

See Card Display for setup details.

​

Token Replacement

Send the card details directly to the hotel’s API with Token Replacement.

• Build an API request to the hotel’s system that contains the card token.
• Tell PCI Booking where the card data goes in the message, with placeholders or a target profile.
• PCI Booking replaces the token with the real card data on the way to the hotel.
• If you use relay restrictions, add the hotel’s endpoint for the user that sends the request.
• If the hotel only accepts traffic from known IP addresses, it must allow PCI Booking’s outbound IP addresses.

​

Token sharing

If the hotel has its own PCI Booking account, associate the token with that account instead of sending the card. See Share a Card Token Between Merchants.

​

Step 4: Make the CVV Available

If the hotel needs the CVV, set a CVV retention policy on the token within 60 minutes of tokenization. Otherwise your account-wide default applies, or, if there is none, the system default (the CVV is kept for one relay or one month, whichever comes first). Card Display with OTP shows the CVV only if the token’s policy includes an OtpCardView (or GeneralProperty) destination.

​

Step 5: Delete the Token

When the hotel no longer needs the card, delete the token.

​

Related

• Working with Third Parties. How the four ways of passing card data to and from third parties fit together.
• Card Display with OTP. OTP-secured card display with no portal needed.
• Third-Party Permissions. Share tokens with other PCI Booking customers.
• CVV Retention Policy. Control how long the CVV is kept and where it can be sent.
• Collect and Process a Payment. Need to charge the card instead of sending it to a hotel?
• Process OTA and Channel Manager Payments. Need to charge a card you received from a third party?