HomeGuideMethod ReferenceAssess YourselfRequest Sandbox Account
Guide
Ask For AssistanceLogin

Tokenization in Request (Gateway)

Suggest Edits

PCI Booking users (e-commerce sites; e.g., OTAs) who work with third parties that send requests containing card data to the PCI Booking user's APIs should use the Tokenization Gateway service.

How It Works

The gateway will behave as a sort of "proxy" or "interceptor" for the e-commerce API. It will be set up in such a way that all requests that should go to the e-commerce API would be routed first through the gateway and, from there, relayed to the e-commerce API.

The gateway will be configured with a site name of the client's choice and will use the SSL certificate from the client.

The gateway will be set up with a profile for each site. The profile will contain a series of message filters, and for each message filter, there will be a set of content filters (a set of instructions that indicate where, in the message, is the credit card information located). The profile will also contain the target URI that the messages passing through the gateway will be relayed to.
The message filter will help the gateway identify which messages should be processed and which should be let pass as is. Once a message was identified to be processed, the gateway will attempt to
process the content of the message using the content filter.

  • If processing is successful, the card data is extracted from the message and tokenized. Masked card data is returned into the message body. The card token URI is added to the header of the message before the message is relayed to the target URI.
  • If processing is unsuccessful, the card data is left as is in the message and a tokenization error is added to the header of the message before the message is relayed to the target URI.
  • If the message filter does not find a match in the message, the message is relayed as is to the target URI.

Request processing

📘

Single or multiple card details in the request

While this process refers to one card and one token, PCI Booking can tokenize all cards listed in the request - as many as are listed - so long that the content filter identifies their respective locations.

A request will be processed as follows:

  • Third party sends a request to the e-commerce's API.
  • PCI Booking intercepts the request and utilizes a pre-set configuration to identify if the message should be processed, and if so, extract the card details from the message body.
  • The PCI Booking server securely stores card data, and issues a card-token.
  • PCI Booking masks the sensitive parts of the original card data, as per the PCI standard.
  • The card token is added to the request in a predefined header name (usually, x-Token)
  • A X-Forwarded-For header is added to the request containing the original request's IP address (read more on configuration of IP address list.
  • If applicable, a tokenization error or warning message is added to the header list (read more on Tokenization Errors and Warnings.
  • The request is relayed to the e-commerce site.
  • The response from the e-commerce site is relayed back to the original sender of the request. If necessary, the e-commerce site can perform a token replacement on the response. For more information, please read Token Replacement in Response (Gateway).
  • Optionally, set the CVV Retention Policy for this token.

📘

Request headers

When a request is sent from the third party to the e-commerce API through the PCI Booking gateway, PCI Booking will add several headers to the request - some for internal diagnostics and some for providing the e-commerce system with additional information.
Read more on processing the request headers added by the gateway.

Setting up a Gateway Endpoint

Setup and configuration of the gateway is done by the PCI Booking support team. In order to set up a new gateway endpoint, please contact our support team and provide the following details:

  • Your username in PCI Booking
  • The target URI that you would like the messages to be relayed to once processing in the gateway has been completed.
  • Information on how to identify messages that contain credit card information. This can be done by one of the following options:
    • URL path of the requests that the sender sends to.
    • Specific header in the request.
  • The structure of the message(s) that should be processed by the gateway (the messages should be either in XML or JSON formats).
  • Information on how you would like the gateway to handle duplicate cards (that is, when a card is passed through the gateway that already exists as a token in PCI Booking). The options are:
    • Eliminate duplicate card= true. This means that if a card that is already stored in PCI Booking as a token passes through the gateway, the gateway will return the same token as the card already stored.
    • Eliminate duplicate card = false. This means that regardless if the card already exists in PCI Booking or not, each card that passes through the gateway will get a new token.
View: https://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgVGhpcmQgcGFydHkgc2VuZGluZyBjYXJkIGRldGFpbHMgLSB3aXRob3V0IHVzaW5nIFBDSSBCb29raW5nCnBhcnRpY2lwYW50AEIHUABEBWFzIGVjABENACsLIEN1c3RvbWVyIGFzIHBjaWJjCgplYy0-KwAHBTogU2VuZCByZXF1ZXN0AHcFAIEDDQpub3RlIG92ZXIANgY6IFN0b3JlABYOAFEFLT4tZQBFCnNwb25zZQo&s=roundgreen

Updated over 4 years ago