> ## 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. # Receiving Cards from Channex > How a PMS, booking engine or vacation rental platform takes guest cards from Channex as PCI Booking tokens, and what to do with the tokens afterwards. Channex names PCI Booking as a tokenization provider in its [Guide to PCI](https://docs.channex.io/guides/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](#part-1-receiving-the-card-from-channex): 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](#part-2-what-to-do-with-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](https://docs.channex.io/api-v.1-documentation/bookings-collection) 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](https://developers.pcibooking.net/capture-cards/tokenization-on-response.md): 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](mailto:support@channex.io): * **IP addresses**: PCI Booking's [outbound IP addresses](https://developers.pcibooking.net/reference/outbound-ips.md). 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](mailto: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](https://developers.pcibooking.net/capture-cards/universal-tokenization.md) for Channex, so there is no profile to write: | Profile name | Fetches | Use it for | | - | - | - | | `Channex` | `https://secure.channex.io/api/v1/bookings/{id}` | Production | | `ChannexStagingSecure` | `https://secure-staging.channex.io/api/v1/bookings/{id}` | Testing with full cards on Channex staging | | `ChannexStaging` | `https://staging.channex.io/api/v1/bookings/{id}` | Testing the plumbing only. This host returns masked cards, so no token is created | 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](https://developers.pcibooking.net/api-reference/tokenize-cards/get-tokenization-profiles.md). If you fetch bookings through a different Channex endpoint, such as a booking revision, create your own [target profile](https://developers.pcibooking.net/account-setup/target-profiles.md) and call it through [Tokenization in Response](https://developers.pcibooking.net/api-reference/tokenize-cards/tokenization-in-response.md) with the Channex URL in `targetURI`. The card sits in `data.attributes.guarantee` of the booking. Send a sample response to [support@pcibooking.net](mailto: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](https://developers.pcibooking.net/api-reference/tokenize-cards/tokenize-on-response-using-preset-profiles.md) with the profile name in the path. You always send `POST` to PCI Booking. PCI Booking calls Channex with the method the profile defines. ```bash theme={null} curl -X POST "https://service.pcibooking.net/api/booker/Channex/reservation?accessToken=your-access-token&pathSegments=id%3D20e076f6-09bd-40c8-8e03-a235196c901a&saveCVV=true&eliminateCardDuplication=true&ref=20e076f6-09bd-40c8-8e03-a235196c901a" \ -H "user-api-key: your-channex-api-key" ``` | Part of the request | What to send | | - | - | | `accessToken` or `sessionToken` | PCI Booking authentication. This endpoint takes an [access token](https://developers.pcibooking.net/getting-started/authentication.md#access-token) or a [session token](https://developers.pcibooking.net/api-reference/general/start-temporary-session.md), not the API key. | | `pathSegments` | `id=` followed by the Channex booking ID. | | `user-api-key` header | Your Channex API key. Headers are passed to Channex unchanged, so send whatever Channex requires. | | `saveCVV` | `true` to keep the CVV on the token. The default discards it. | | `eliminateCardDuplication` | `true` to get the existing token back when the card is already stored. See [Booking modifications](#booking-modifications). | | `ref` | Your own reference, for example the booking ID, so you can find the token later with [Query Tokens](https://developers.pcibooking.net/api-reference/manage-tokens/query-tokens.md). | ### 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](https://developers.pcibooking.net/capture-cards/cvv-retention-policy.md) 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](https://developers.pcibooking.net/capture-cards/tokenization-on-response.md#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](https://developers.pcibooking.net/getting-started/testing-and-going-live.md). ## 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](https://developers.pcibooking.net/use-tokens/card-display.md): 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](https://developers.pcibooking.net/use-tokens/card-display-otp.md): 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](https://developers.pcibooking.net/capture-cards/cvv-retention-policy.md#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](https://developers.pcibooking.net/capture-cards/cvv-retention-policy.md) 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](https://developers.pcibooking.net/use-tokens/universal-payment-gateway.md) to charge the token through the property's own PSP account. You store [PSP credentials](https://developers.pcibooking.net/account-setup/gateway-credentials.md) 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](https://developers.pcibooking.net/use-cases/multi-hotel-gateway-routing.md) 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](https://developers.pcibooking.net/api-reference/process-cards/get-payment-gateways.md). If a hotel's provider is not on it, we can add it; see [Supported PSPs](https://developers.pcibooking.net/use-tokens/universal-payment-gateway.md#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](https://developers.pcibooking.net/use-tokens/token-replacement-in-request.md). 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](https://developers.pcibooking.net/account-setup/security-settings.md#relay-restrictions) if your account uses them, and give the destination PCI Booking's [outbound IP addresses](https://developers.pcibooking.net/reference/outbound-ips.md) if it allow-lists callers. ### Take cards in your own booking engine For direct bookings on your own engine, the [Hosted Card Entry Form](https://developers.pcibooking.net/capture-cards/hosted-card-entry-form.md) collects the card in an iframe on your page, and [Card By Link](https://developers.pcibooking.net/capture-cards/card-by-link.md) 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](https://developers.pcibooking.net/api-reference/manage-tokens/delete-token.md) 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](https://developers.pcibooking.net/manage-tokens/delete-tokens.md) and [Token Lifetime](https://developers.pcibooking.net/concepts/tokenization-explained.md#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 > [card] [Tokenization on Response](https://developers.pcibooking.net/capture-cards/tokenization-on-response.md) > > The capture method behind the Channex profile. > [card] [Universal Tokenization Profiles](https://developers.pcibooking.net/capture-cards/universal-tokenization.md) > > How ready-made profiles work. > [card] [Send a Guest's Card to a Hotel](https://developers.pcibooking.net/use-cases/capture-and-send-to-hotel.md) > > Choose how each hotel receives the card. > [card] [Testing and Going Live](https://developers.pcibooking.net/getting-started/testing-and-going-live.md) > > Sandbox, test data and the move to production. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.