Tokenization on Request (Gateway)

​

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. If the message does not match any filter, it is relayed as-is to the target URI without modification.
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.

​

What PCI Booking Adds to the Request

• 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

​

Setting Up a Gateway Endpoint

• 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. If the new message includes a CVV, it’s stored on the existing token and its CVV retention policy is reset to your account default - see CVV Policy and Duplicate Card Handling.
  • No deduplication (false). Every card processed gets a new token, regardless of whether it already exists.

​

Payload Requirements

• Minimum required fields: the card number (PAN) and expiration date.
• The gateway can tokenize both card data and 3DS authentication results.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soap:Body>
      <AcceptFromMeCC>
         <payCard>
            <ccInfo>
               <Cc_type>Visa</Cc_type>
               <FirstName>John</FirstName>
               <LastName>Doe</LastName>
               <Cc_number>4580458045804580</Cc_number>
               <Cc_date_month>10</Cc_date_month>
               <Cc_date_year>2028</Cc_date_year>
               <Cc_cvv>123</Cc_cvv>
               <AuthenticationValue>AAACBDgxAnlENWNRSTECEwAAAAA=</AuthenticationValue>
               <eci>05</eci>
               <id>cnFwcXVLRjlKZ2pPeGpySzJieGQ=</id>
               <Version>1.0</Version>
            </ccInfo>
         </payCard>
      </AcceptFromMeCC>
   </soap:Body>
</soap:Envelope>

​

Timeout and Failure Handling

​

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