Skip to main content
Channex names PCI Booking as a tokenization provider in its Guide to PCI. If you connect a property management system, booking engine or rental platform to Channex and want the guest’s card without taking on PCI DSS scope, this guide covers the two halves of that integration:
  1. Receiving the card: the one capture method that works with Channex, the profile to use, the exact request, and what Channex needs from you first.
  2. Using the token: what systems like yours usually add once the card is a token, with a link to the page for each.

​
Part 1: Receiving the Card from Channex

​
How Channex releases card data

Channex attaches the guest’s card to a booking as the guarantee object. On the standard API host the card number and CVV in that object are masked. Channex returns the full card only on its secure hosts, secure.channex.io for production and secure-staging.channex.io for staging, and only to callers it has allow-listed after receiving their PCI DSS attestation. Channex’s booking webhook carries identifiers only, not the card, so the booking must be fetched from the API. See the Channex Bookings API for the object and the secure hosts. That shape decides the capture method. The booking is fetched, not pushed, so you use Tokenization on Response: you send the fetch through PCI Booking, PCI Booking calls the Channex secure host, tokenizes the card in the response, and returns the booking to you with the card masked and the token in a header. Because PCI Booking makes the call, it is PCI Booking’s address that Channex sees, and PCI Booking’s attestation that Channex verifies.

​
Step 1: Ask Channex to allow-list PCI Booking

Before Channex returns a full card to anyone, it needs the caller’s IP addresses and PCI DSS attestation. Send both to support@channex.io:
  • IP addresses: PCI Booking’s outbound IP addresses. These are the addresses the call to the secure host comes from. Your own addresses are not involved in that call.
  • PCI DSS attestation: PCI Booking’s Attestation of Compliance. Request it from support@pcibooking.net.
Until Channex confirms the allow-list, the secure host answers with masked or empty card data and nothing is tokenized.

​
Step 2: Use the Channex universal profile

PCI Booking maintains ready-made universal profiles for Channex, so there is no profile to write: Each profile takes one path segment, id, which is the Channex booking ID. The profile reads the guarantee object of the booking: card number, expiration date, cardholder name, CVV and card type. The current list of universal profiles, with each one’s path segments, is returned by Get Tokenization Profiles. If you fetch bookings through a different Channex endpoint, such as a booking revision, create your own target profile and call it through Tokenization in Response with the Channex URL in targetURI. The card sits in data.attributes.guarantee of the booking. Send a sample response to support@pcibooking.net and our team builds the content filter for you.

​
Step 3: Send the fetch through PCI Booking

Call Tokenize on Response Using Preset Profiles with the profile name in the path. You always send POST to PCI Booking. PCI Booking calls Channex with the method the profile defines.

​
What comes back

  • Status 201: a new token was created. Status 200: the card already existed and eliminateCardDuplication returned the existing token.
  • X-pciBooking-cardUri header: the token URI. Store it against the booking in your system.
  • Body: the Channex booking as Channex sent it, with the card number, cardholder name and CVV masked in the guarantee object. The expiration date, card type, is_virtual and meta are not card data and come back unchanged, so your existing parsing of the booking keeps working.
  • X-pciBooking-Tokenization-Errors and X-pciBooking-Tokenization-Warnings headers: present only when something went wrong with the card, for example a number that failed validation. Log them.
  • Any non-2xx status from Channex is passed to you unchanged, with Channex’s own body, and nothing is tokenized. A 401 from Channex usually means the Channex API key is wrong or the allow-list is not in place yet.
The CVV is stored only when you send saveCVV=true, and then the CVV retention policy decides how long it stays and what it may be used for. Set a per-token policy within 60 minutes of tokenization, or set an account-wide default once and let it apply to every token.

​
Virtual cards

Virtual cards from OTAs arrive in the same guarantee object, with is_virtual set to true and a meta object holding the balance, currency and activation dates. PCI Booking captures a virtual card exactly like any other card. The meta fields are not card data, so they stay readable in the response and you keep them in your system alongside the token.

​
Booking modifications

When Channex sends the same booking again after a modification, the same card arrives again. Send eliminateCardDuplication=true on every fetch and PCI Booking returns the token you already hold (status 200) instead of creating a second one. A duplicate is a card with the same number and expiration date. If the fetch carries a CVV, it is stored on the existing token and that token’s CVV retention policy is reset to your account default. See Duplicate Card Handling.

​
Testing

Use a PCI Booking sandbox account with the ChannexStagingSecure profile against a Channex staging property. Ask Channex to allow-list PCI Booking’s addresses for staging as well as production. See Testing and Going Live.

​
Part 2: What to Do with the Token

Once the card is a token, these are the things systems connected to Channex most often add. Each one works with the token from Part 1 as it is.

​
Show the card to hotel staff

Most properties key the card into their own terminal, so staff need to see it. Two options:
  • Card Display: an iframe inside your own portal. You decide who may log in and who may view cards. The card renders inside PCI Booking’s domain, so nothing reaches your servers.
  • Card Display with OTP: a hosted page when you have no portal or do not want to manage viewer access. PCI Booking emails the viewer a link and verifies their phone with a code before showing the card.
Whether the CVV is shown depends on the token’s CVV retention policy. Viewing in your own portal is the Owner destination; the hosted page is OtpCardView. See Destination Types.

​
The CVV

PCI DSS does not allow the CVV to stay with the card once the card has been used. Your CVV retention policy is where you define what “used” means for your business: how long the CVV may stay, and how many times it may go to each destination, for example a hotel viewing it or a charge through a payment gateway. The policy cannot be changed on an existing token, so decide it before the first Channex booking is tokenized.

​
Charge through the hotel’s own payment provider

Use the Universal Payment Gateway to charge the token through the property’s own PSP account. You store PSP credentials once per hotel under a credentialsId of your choosing, then name that ID on each charge, pre-authorization, capture or refund. The money settles with the hotel. Charge Multiple Hotels’ Gateways From One Account walks through the pattern. Adyen, Stripe, Viva and Authorize.Net are among the integrated gateways. For the current list, with each gateway’s capability flags, call Get Payment Gateways. If a hotel’s provider is not on it, we can add it; see Supported PSPs for what to send us.

​
Send the card to any HTTPS endpoint

When a property’s acquirer or system is not on the gateway list but has an API, use Token Replacement in Request. You build the request the way that API expects it, with the token in place of the card, and send it through PCI Booking. PCI Booking inserts the card number in transit. Register the destination under relay restrictions if your account uses them, and give the destination PCI Booking’s outbound IP addresses if it allow-lists callers.

​
Take cards in your own booking engine

For direct bookings on your own engine, the Hosted Card Entry Form collects the card in an iframe on your page, and Card By Link sends the guest a secure link by email or SMS. Both produce the same kind of token as a Channex booking, so everything in this part applies to them too.

​
Retention and deletion

Tokens do not expire on their own. Delete a token with Delete Token when the booking no longer needs it, for example a set number of days after departure, driven from your own system. If a token without a CVV has no value to you, set DeleteCardUponCvvCleanup on the CVV retention policy and the token is removed when its CVV is cleared. See Delete Tokens and Token Lifetime.

​
Many hotels on one account

One PCI Booking account serves all your properties. Use ref on each tokenization to tag the token with your booking or property reference, store one set of PSP credentials per hotel, and route each transaction with credentialsId. The hotels do not need PCI Booking accounts of their own.

​
Next Steps

Tokenization on Response

The capture method behind the Channex profile.

Universal Tokenization Profiles

How ready-made profiles work.

Send a Guest's Card to a Hotel

Choose how each hotel receives the card.

Testing and Going Live

Sandbox, test data and the move to production.