Skip to main content
A target profile is a reusable configuration that tells PCI Booking how to exchange card data with a specific third party. Each profile defines the message format, where card fields are located, and what certificates to use for the connection. Profiles are used by: You create a profile once per third-party message format, then reference it by name in your API calls.

​
Profile Settings

At least one content filter (tokenization or retrieve cards) is required. A profile used only for tokenization needs only the tokenization filter. A profile used only for token replacement needs only the retrieve cards filter. Many profiles have both.

​
Two Types of Content Filters

Each profile can contain two separate content filters, each serving a different direction of data flow:
  • Tokenization filter - tells PCI Booking how to read card data from the message (for tokenization operations). PCI Booking locates the card fields, extracts the values, stores them securely, and replaces them with tokens.
  • Retrieve cards filter - tells PCI Booking how to write card data into the message (for token replacement operations). PCI Booking locates the token placeholders and injects the real card data.
In many cases the same XML structure works for both directions, but some integrations require different selectors for reading vs. writing.

​
Custom Encryption and Decryption

Some third parties require the message itself to be encrypted or signed - beyond HTTPS transport encryption. PCI Booking supports this with per-third-party crypto modules:
  • Custom encryption (outbound) - when the third party requires the request to be encrypted or signed after the card data has been injected into it, select a Custom Encryption Name on the profile. During token replacement, PCI Booking merges the card data and then applies the selected module to encrypt or sign the payload according to the third party’s specification before sending. Modules may use the profile’s Content Signing Certificate and Encryption Public Key, depending on the third party’s scheme.
  • Custom decryption (inbound) - when the third party’s message must be decrypted before PCI Booking can parse it and tokenize the card data, a custom decryption module is configured on your profile. During tokenization operations, PCI Booking decrypts the incoming content first and then applies your tokenization content filter. Custom decryption modules are configured on your profile by the PCI Booking support team.
The available encryption modules appear in the Custom Encryption Name dropdown in the profile settings. Modules already exist for several third parties (for example Elong, Ctrip, Air France, Visa).
Need to integrate with a third party whose encryption or decryption scheme is not in the list? Send the specification (algorithm, keys/certificates, message format) to support@pcibooking.net. Our team implements the module in PCI Booking, and it then becomes selectable in your profile settings.

​
Custom Tokenization

By default, card data captured through a profile is stored in PCI Booking’s vault and you receive a PCI Booking token. With Custom Tokenization, the captured card is instead sent to an external tokenization provider, and that provider’s token is returned to you. Use this when your downstream systems work with tokens from a specific tokenization service rather than PCI Booking tokens, while still using PCI Booking to intercept and extract the card data from third-party messages. Select the provider in the Custom Tokenization dropdown of the profile settings. Sandbox accounts are automatically routed to the provider’s test environment.
Need a tokenization provider that is not in the list? Contact support@pcibooking.net with the provider’s tokenization API details and our team will add it.

​
Creating a Profile

  1. Log in to the PCI Booking portal.
  2. Navigate to PCI Shield Settings > PCI Shield Profile Settings.
  3. Click the plus icon to create a new profile.
  4. Enter a Name (alphanumeric, cannot be changed later).
  5. Configure the settings from the table above.
  6. Add at least one content filter (tokenization, retrieve cards, or both). The built-in filter editor offers sample templates, autocomplete, and validation - see Writing Filters in the Portal.
  7. Save the profile.
From this screen you can also view, edit, clone, or delete existing profiles.
Editing a content filter (tokenization or retrieve cards XML) is a two-step process. Clicking Apply XML in the filter editor only validates the XML and stages it in the browser - it does not save it. You must also click the Save (floppy disk) icon in the profile row afterward, or the change is lost. Other fields (Name, Description, certificates, etc.) don’t need the Apply step, but still require the row-level Save.
The profile Name cannot be changed after creation. Choose a descriptive name that identifies the third party and message format (e.g., BookingComXML, SabreGDS).

​
Universal Profiles (Pre-Built)

Many PCI Booking customers connect to the same third parties (booking platforms, OTAs, channel managers, GDS providers). For these common integrations, PCI Booking maintains universal profiles that are already built and ready to use. Reference the universal profile name in your request instead of creating a custom one. Check with support@pcibooking.net to see if a universal profile already exists for your third party.
Need help creating a custom profile? Send a sample of the message you exchange with the third party to support@pcibooking.net and our team will build the profile for you. Already wrote your own content filter? Send it with a sample message and the team will validate it for you.

​
Next Steps

Content Filters

Define where card fields appear in a message using selectors

Client Certificates

Upload certificates for mutual TLS

Tokenization on Response

Tokenize card data from third-party responses

Token Replacement in Request

Replace tokens with real card data in outbound requests