Skip to main content
A content filter is an XML configuration within a target profile that tells PCI Booking exactly where card data fields are located in a message. Content filters are used for both tokenization (extracting card data) and token replacement (injecting card data). The field selectors are declared inside a <content> element for tokenization filters, and inside a <replace> element for token replacement filters.

Writing Filters in the Portal

You do not have to write content filters by hand. The PCI Booking portal includes a dedicated filter editor: go to PCI Shield Settings > PCI Shield Profile Settings and click the edit (pencil) icon on a profile’s Tokenization or Retrieve cards column. The editor gives you:
  • Sample templates - a dropdown loads a ready-made base filter for each combination of message format (XML or JSON) and direction (tokenization or token replacement). Pick the closest template and adjust the selectors to your message structure.
  • Intellisense - as you type <, a space, or = (or press Ctrl+Space), the editor suggests the valid elements, attributes, and attribute values at that position: the <transform> root, <content>/<replace> children, every card field element, format values, and the full card type name list for type mapping.
  • Validation - clicking Apply XML validates the filter on the server before saving. Any structural errors are listed in the editor so you can fix them immediately.
The sections below explain the filter syntax the editor produces.
You are not on your own. At any point, contact support@pcibooking.net to:
  • Validate your filter - send your content filter together with a sample message and our team will confirm it is accurate before you go live.
  • Have a filter built for you - send a sample of the message you exchange with the third party and our team will create the content filter for you.

Supported Message Formats

Content filters support four message formats. Set the type attribute on the <transform> element to match your message format. PCI Booking detects whether body content is XML, JSON, or form-encoded based on the content type header.

Content Filter Structure

A content filter is an XML document whose root element is <transform> in the http://www.pcibooking.net/pciShieldProfiles namespace:
The root element must be <transform> with the xmlns="http://www.pcibooking.net/pciShieldProfiles" namespace declaration exactly as shown. Filters with a different root element or a missing namespace are rejected.
The <content> element’s selector attribute points to the parent element containing card fields. Each child element then uses a relative selector to locate its specific field within that parent. For token replacement filters, use a <replace> element instead of <content> - the structure inside is the same.

Format Examples

For XML messages, use XPath expressions. Use local-name() to match elements regardless of XML namespace prefix.Tokenization filter (extracting card data):
Token replacement filter (injecting card data) - note the <replace> element:

Card Data Fields

Each <content> element can map the following card fields:
nameOnCard is stored up to 32 characters. If the source field can be longer, use substring="0,32" to truncate it - otherwise tokenization fails validation (see Card Validation Errors).

Format Attributes

The format attribute controls how date fields are read and written:
  • expYear: YYYY (default, four digits) or YY (two digits)
  • expMonth: MM (two digits with leading zero) or M (default, no leading zero)

Substring Extraction

When a third party combines multiple values into a single field, use substring extraction to isolate the part you need.
  • substring - extracts a portion of the value when reading from the message (tokenization). Format: "startPosition" or "startPosition,length" (zero-based).
  • dataSubstring - extracts a portion of the replacement data when writing to the message (token replacement). Same format as substring.
Example: expiration date sent as 0125 (MMYY) in a single field:

Card Type Mapping

When a third party uses different card type codes than PCI Booking, add mapping entries as child elements of the <type> field. Each entry’s element name is PCI Booking’s card type name, and its content is the third party’s code.
See Supported Card Types for the full list of PCI Booking card type names.

3D Secure Fields

Content filters can also map 3DS authentication data alongside card fields. Add these inside a <threeDs> wrapper element, which sits as a sibling of the card field elements inside <content>: Example with 3DS fields:
The 3DS selector elements are only read from inside the <threeDs> wrapper. Placed directly inside <content>, they are ignored.

Multiple Cards in One Message

If a message contains multiple cards (e.g., a batch of reservations), add a reservationSelector attribute to the <content> element. This XPath expression identifies each repeating card block, and PCI Booking processes each one independently.
PCI Booking iterates over every element matching reservationSelector and applies the card field selectors within each.

Next Steps

Target Profiles

Create and manage profiles that use content filters

Supported Card Types

Full list of card type values for card type mapping

Tokenization on Response

Tokenize card data from third-party responses

Token Replacement in Request

Replace tokens with real card data in outbound requests