Booking.com connectivity partners and PCI Booking
Pass Booking.com's PCI review every year without holding a single card
Booking.com asks every connectivity partner that receives guest or virtual cards to attest its own PCI DSS compliance, annually, or lose access to card data. Pull your reservations through PCI Booking and the card never reaches your servers: you keep the partnership and the attestation covers only what is left in your systems.
Ready-made Booking.com profiles since 2017 · PCI DSS Level 1 service provider · Free sandbox and support
Level 1
PCI DSS service provider
ISO 27001
Certified to ISO 27001:2022
120+
Payment integrations, one API
2016
First Booking.com partner connected
The rules you are working under
What Booking.com asks of a connectivity partner that wants card data
From Booking.com's Connectivity Hub. None of it is negotiable per partner, and it is reviewed again every year.
Your own attestation, every year
To receive card details you file an Attestation of Compliance in your own name. Up to 300,000 transactions a year that comes from the self-assessment questionnaire you complete on Booking.com's compliance platform; above that, from an onsite assessment by a Qualified Security Assessor. It lapses after twelve months, and so does your card access if it is not renewed.
A compliant vendor does not make you compliant
Booking.com's own FAQ asks the question and answers it: no. Using a PCI DSS certified provider does not replace your attestation. What it does is change which questionnaire you qualify for and how much of it applies, because the questions follow the card data, and the card data is no longer in your systems.
Cards come from a separate secure host, once
Reservations with card data are served from Booking.com's dedicated secure endpoint, and the full card details are included in the first pull only. A modification does not repeat them unless the card itself changed. Whatever reads that first response has to be in scope, or has to be us.
The partner decides card delivery, per property
Whether a property's reservations carry the full card, the card without the CVC, or nothing but an extranet link is a setting on the partner's side of the Provider Portal. Booking.com changes it on the partner's request only, never the hotel's. Your hotels will ask you for the cards, and you have to be able to take them.
In 2026 Booking.com moved partner PCI attestations from its PCI Portal to Panorays, the third-party risk platform used across Booking Holdings. Expiry dates carried over; renewals now run there.
Where PCI Booking fits
Your platform pulls the reservation. We take the card out on the way through.
Your platform pulls reservations from Booking.com's secure endpoint as it does today, but the call goes through PCI Booking. We replace the card number and CVC in the response with a token and keep the card in our vault. Everything else in the reservation, the guest name included, comes back to you as Booking.com sent it.
What stays with you
Your connectivity partnership, your machine account and credentials, your reservation logic, your hotel relationships, and your attestation. Booking.com sees your partner account calling, from an address you have allow-listed, with your credentials.
What moves to us
The connection to Booking.com's secure host, the card number and CVC, their storage, and every later use of the card: charging it, showing it to a hotel, sending it to a hotel's payment provider or PMS. Your systems hold a token that cannot be used anywhere else.
What we provide you to support your attestation
Our PCI DSS Attestation of Compliance, our Shared Responsibility Matrix, which lists each PCI DSS requirement and says whether we carry it or you do, and a QSA-written note on attesting as a service provider that has outsourced card handling. You attach them to your questionnaire; they answer the questions about the card data you no longer hold.
Nothing to parse, nothing to configure
Three ready-made Booking.com profiles, in production use since 2017
A profile tells us where to send your request and where the card sits in Booking.com's response. These three cover both of Booking.com's reservation formats. Connectivity partners have been pulling their Booking.com reservations through them for years; you use the one that matches the endpoint you already call.
| Profile | Booking.com endpoint it calls | For |
|---|---|---|
| Booking_com | B.XML reservations | Partners on the classic XML reservations feed |
| BookingComReservationRequest | OTA_HotelResNotif | New reservations on the OTA format |
| BookingComModificationRequest | OTA_HotelResModifyNotif | Modifications on the OTA format |
Each parses the card number, expiry, cardholder, CVC and card type. Your Booking.com credentials, whether in the XML body or a bearer token header, pass through to Booking.com untouched. Virtual-card attributes such as balance and activation date are not card data and come back to you as sent.
What we have learnt from years of Booking.com traffic
Four Booking.com behaviours to design for
All four are Booking.com's, not ours. Partners who know them up front do not lose reservations or open support tickets over them.
The first pull is the only pull
On the B.XML feed a reservation leaves Booking.com's queue the moment it is served, card and all. If your side drops that response, the card is gone. Treat every pull as a one-shot read: the token stored before you acknowledge, and nothing in your pipeline that can drop the response once it has arrived. The OTA endpoints let you confirm receipt explicitly, which is one reason partners move to them.
Three zeros in the CVC field means no CVC
When the guest gave no CVC, the B.XML feed sends three zeros rather than an empty field; the OTA format omits the field instead. Booking.com has acknowledged the B.XML behaviour as a bug. Until it is fixed, a CVC stored as three zeros from a B.XML reservation is not a CVC.
Virtual cards are cards, with extra fields
A Booking.com virtual card arrives in the reservation like a guest card and is tokenised the same way. Its activation date, balance and expiry travel alongside, unparsed, so your platform can schedule the charge. Whether the CVC is still there when you charge depends on the CVC retention rule you set.
No 3-D Secure comes with the card
Booking.com collected the card, so no authentication result travels with it, for guest cards or virtual cards. Acquirers that insist on strong customer authentication for every transaction will soft-decline them. Settle with your hotels' acquirers how these cards are flagged before the first charge, not after.
Beyond the pull
Everything your hotels do with a Booking.com card, done on the token
Charge it through the hotel's own provider
One API, 120+ payment integrations. Each hotel's credentials sit under your account; you name them on the transaction and we send the card. A provider your hotels use that is not on the list is added on demand at no additional cost: request an integration.
Show it to hotel staff
For hotels that key the card into their own terminal, a one-time link with an emailed or texted code opens the card in a time-limited view. No accounts for the hotel to maintain, nothing for you to build beyond the call that creates the link.
Forward it to a PMS that insists on the card
Build the message your downstream system expects with the token in it; we replace the token with the card in transit, over HTTPS to any endpoint you register. Your servers never assemble a message that contains a card number.
Take cards from Expedia and the channel managers the same way
Ready-made profiles exist for Expedia and the major channel managers, and a custom profile covers any other partner that returns cards in a response. One token format across all of them.
Keep the CVC exactly as long as the rules allow
PCI DSS does not allow the CVC to be kept after the card has been authorised. You set the rule that says when that point is reached for your flow, within a ceiling, and the CVC is removed at that point. Everything else about the token keeps working.
Delete on your schedule
A token is deleted with one call. Most partners do it from their own scheduler once the stay is settled, so the vault holds only cards that still have a use.
Step by step
From sandbox to your next Booking.com attestation
Seven steps. Three are on Booking.com's side, and we tell you exactly what to put there.
Step 1 · You, two minutes
Request a free sandbox
Name, company, email and phone. That is the whole form.
The sandbox is a copy of production, and it stays free for as long as you're a customer.
Step 2 · Us
We send the sandbox details and the API documentation
We open your sandbox account and email you the details. Your keys, your portal login, the developer documentation, and the guide for Booking.com connectivity partners: which profile matches your feed, the request to send, what comes back, and how virtual cards and modifications behave.
Step 3 · You, in the Booking.com Provider Portal
Allow-list PCI Booking's outbound addresses on your machine account
Booking.com checks the address a request comes from against the allow-list on your machine account. With PCI Booking in the path, that address is ours. Add the addresses on our outbound IP page to the account you use for reservations. The same addresses serve sandbox and live, and other partners' Booking.com accounts already carry them.
A 401 from Booking.com on the first pull almost always means this step was skipped. We pass Booking.com's response through unchanged, so you will see it.
Step 4 · You, one change in your code
Point your reservation pull at the Booking.com profile
Take the request your platform already sends to Booking.com's secure endpoint. Send it to the PCI Booking profile that matches it instead, with your Booking.com credentials exactly as they are and the usual hotel and last-change parameters forwarded. The response you get back is Booking.com's, with the card number and CVC removed and a token in the header. Everything downstream keeps working on the token.
Step 5 · You and your hotels, as needed
Add what your hotels need done with the card
Charges through each hotel's own payment provider, 3-D Secure for cards you collect yourself, the one-time card view for front desks, forwarding to a PMS, cards on file. Each is an API call on the token.
Step 6 · You and our sales team
Agree the commercials and open your live account
Tell us your monthly reservation and card volume and we quote a plan. The agreement is drafted and signed, the live account is opened, and you receive production keys. Your sandbox stays open.
Step 7 · You, on Booking.com's compliance platform
Complete your attestation with our documents attached
Fill in the questionnaire that matches what is left in your systems. Ask us for the document pack below; our Shared Responsibility Matrix tells you, requirement by requirement, which answers are ours. File your Attestation of Compliance with it. Then point production at the live endpoint with your production keys, and go.
Renewal a year later is the same questionnaire with the same answers, plus our current Attestation of Compliance, which we reissue every year.
The paperwork
What goes into your Booking.com attestation from us
We provide, on request
- Our PCI DSS Attestation of Compliance
Level 1 service provider, assessed annually by a QSA. Reissued each year; the current one is always the one you attach. - Shared Responsibility Matrix
Every PCI DSS requirement, marked as ours, yours, or shared, for the services you use. - QSA note on attesting as a service provider
Written by a Qualified Security Assessor: how a provider that has outsourced card handling completes its questionnaire. - Outbound IP list and ISO 27001 certificate
The addresses for your Booking.com allow-list, and the certificate for any information-security questionnaire that comes with the risk assessment.
You still do yourself
- Your own questionnaire and Attestation of Compliance
Booking.com requires it in your name. With cards out of your systems, far fewer of the questions apply, and the matrix shows which. - Any vulnerability scan Booking.com asks for
Booking.com may ask for an Approved Scanning Vendor certificate for your externally facing systems. - Your machine account and its allow-list
Booking.com talks to its connectivity partners, not to their vendors. We cannot change anything on your Booking.com account.
FAQ
Questions Booking.com partners ask us
Has Booking.com approved PCI Booking?
Booking.com does not approve or list vendors; it reviews each partner's own attestation. Connectivity partners have been pulling their Booking.com reservations through PCI Booking since 2016 and attesting with our documents attached, and Booking.com's allow-lists carry our addresses under those partners' accounts. That is the arrangement Booking.com's rules allow for, and it has held through every annual review since.
Do we still need our own Attestation of Compliance?
Yes. Booking.com is explicit that a vendor's compliance does not transfer. What changes is the questionnaire: with no card data stored, processed or transmitted by your systems, most requirements are answered by our matrix rather than by your infrastructure.
Which questionnaire should we complete?
That depends on what remains in your systems, and it is your assessor's call or Booking.com's, not ours. We are not a QSA. Our Shared Responsibility Matrix and the QSA note are written so that whichever questionnaire applies, you can show which requirements PCI Booking carries.
We already pull from Booking.com with our own code. How much changes?
The destination of one request. Your credentials, parameters and parsing stay as they are, except that where you used to read a card you now read a token from the response header. Partners typically make the change in a day and test it against their own Booking.com test property.
Can you give us test reservations?
No. PCI Booking is not a Booking.com connectivity partner and holds no Booking.com account. You test with your own partner account and a test property, exactly as you would without us, with the sandbox in the path.
We connect to Booking.com through Channex, not directly.
Then the cards reach you through Channex and the arrangement is different: Channex accepts a tokenisation provider's attestation on your behalf. See the Channex page.
What does it cost?
You pay per card operation: tokenizing, sending, showing or charging a card, with volume discounts. The sandbox and support during the build are free, and you pay only when you go live. See the pricing page, or tell us your monthly reservation volume for a quote.
Tell us when your next Booking.com attestation is due
If it is in the next few months, start with the sandbox now and file this year's questionnaire with the cards already out of your systems.