Skip to main content
Tokenization on Request lets you intercept inbound HTTP requests from third parties before they reach your systems. PCI Booking sits as a gateway in front of your API. When a third party sends a request containing card data, PCI Booking tokenizes the card details and forwards a sanitized version to you. You never see raw card numbers. This is the reverse of Tokenization on Response, where you send a request to a third party and tokenize the response. Here, the third party sends a request to you, and PCI Booking tokenizes the request. This is also the mirror of Token Replacement in Response in the Use Tokens section. Both use the same gateway infrastructure, but in opposite directions: Tokenization on Request tokenizes card data in the third party’s inbound request, while Token Replacement in Response detokenizes tokens in your outbound response.

​
How It Works

  1. PCI Booking sets up a gateway endpoint. The gateway is configured with your SSL certificate and a custom site name. Third parties send their requests to this gateway URL instead of directly to your API.
  2. Third party sends a request. The request arrives at the PCI Booking gateway.
  3. Message filtering. The gateway checks the request against pre-configured message filters (based on URL path or specific headers) to determine if the message should be processed.
  4. Card extraction and tokenization. If the message matches a filter, PCI Booking parses the message body using content filters that define where card data is located. All matching cards are tokenized.
  5. Sanitized relay. PCI Booking masks the card details in the message body, adds the token URIs to a request header (typically x-Token), and forwards the amended request to your API.
  6. Response relay. Your API’s response is relayed back to the original sender.
While the flow above refers to one card, PCI Booking can tokenize all cards in the request, as many as are present, as long as the content filter identifies their locations.

​
What PCI Booking Adds to the Request

Before forwarding the request to your API, PCI Booking adds several headers:
  • Token header (typically x-Token). Contains the token URI(s) for the card(s) found in the request.
  • X-Forwarded-For. The original sender’s IP address.
  • Error/warning headers. If tokenization fails or encounters issues, diagnostic information is added.

​
Target Profiles

The gateway uses a target profile to know where card data appears in the inbound request and how to tokenize it. Each profile includes content filters that define the location of card fields in the message. The PCI Booking support team configures this as part of the gateway setup.

​
Setting Up a Gateway Endpoint

Gateway setup is done by the PCI Booking support team. To set up a new gateway endpoint, contact support@pcibooking.net with the following details:
  • Your PCI Booking username.
  • The target URI where processed messages should be relayed to (your API endpoint).
  • How to identify requests that contain card data. This can be based on URL path or a specific request header.
  • A sample of the message structure (XML or JSON) that should be processed.
  • How to handle duplicate cards:
    • Eliminate duplicates (true). If a card already exists as a token, the existing token is returned.
    • No deduplication (false). Every card processed gets a new token, regardless of whether it already exists.

​
Use Cases

  • Receiving reservation or booking requests from OTAs or channel managers that include card details.
  • Any scenario where a third party pushes card data to your API and you want to keep card data off your servers.

​
Next Steps

Tokenization on Response

The reverse direction. Tokenize card data in responses from third parties.

Capture Cards Overview

All available tokenization methods.