Skip to main content
This is the common pattern for booking platforms, resellers, and channel managers that capture a guest’s card once but need the charge to settle into a specific hotel’s own PSP account, not the platform’s. You keep a single PCI Booking account and a single tokenization estate; each hotel gets its own stored PSP credential set, and you pick which one to use per transaction.

​
How It Works

  • You hold one PCI Booking account.
  • You store one PSP credential set per hotel (see PSP Credentials), each under a credentialsId of your choosing, for example pelecard-hotel-1234. Storing credentials is restricted to your account, so hotels never see or manage keys.
  • You tokenize the guest’s card once, using any card capture method.
  • On every PreAuth and Capture, you pass the token together with the credentialsId for that specific hotel. The transaction goes to that hotel’s terminal and the funds settle directly to the hotel.
  • The token itself never moves and stays owned by your account. The same token can be routed to a different hotel’s terminal on a later transaction just by changing the credentialsId — for example if a booking is transferred between properties.
This is different from sharing a token between merchants, which grants a second PCI Booking account access to a token you own. Here there is only one PCI Booking account (yours); the hotels are your payment gateway credentials, not separate PCI Booking customers.

​
Step 1: Store Each Hotel’s PSP Credentials

For each hotel, store its PSP credentials under a credentialsId you choose:
See Store Gateway Credentials for the full request, and Retrieve Credential Structure or Gateway Guidance for the exact credential field names a specific PSP requires.

​
Step 2: Tokenize the Guest’s Card

Capture the card once, using whichever method fits your flow — Hosted Card Entry Form, Card By Link, or Tokenization on Response if you’re already receiving the card from an OTA or channel manager.

​
Step 3: PreAuth at Booking, Capture Later

Place a PreAuth for the predefined amount at booking time, referencing the hotel’s credentialsId:
Later, capture using the same credentialsId and the original transaction reference. See Authorize & Capture for the full flow, including partial captures.
Voiding or releasing an unused PreAuth hold, and how long a hold lasts before it expires on its own, both depend on the PSP and the card issuer, not on PCI Booking. Check Gateway Guidance for your specific PSP before relying on this in your cancellation flow.

​
Giving the Hotel a “Charge” Button

You have two options for letting the hotel trigger the capture:
  • The button lives in your own extranet or portal. The hotel clicks it, your backend calls PCI Booking with the correct credentialsId. Simplest option — the hotel touches nothing of PCI Booking’s directly.
  • The hotel gets its own user under your account with its own API key (see Manage Users and API Keys), and calls PCI Booking directly with a token you’ve made available to them. Card data is never returned, so the hotel can transact on the token without ever being able to see the card.

​
Adding 3D Secure Liability Shift

If the guest is present at card capture, you can authenticate with 3DS at that point and reuse the authentication for the later PreAuth and Capture — the cardholder does not need to be present again. Because each hotel is a distinct merchant of record for liability-shift purposes, each one needs its own 3DS merchant details registered with PCI Booking. See the “you collect and charge on behalf of multiple merchants” scenario in 3DS Merchant Setup.