Skip to main content
Token Replacement in Request lets you send an HTTP request through PCI Booking as a transparent proxy. PCI Booking replaces card tokens in your request with real card data, forwards the request to the destination, and returns the response. Your systems never handle sensitive card details. This is the mirror of Tokenization on Response in the Capture Cards section. Both use the same forward proxy infrastructure, but in opposite directions: Tokenization on Response tokenizes card data in the third party’s response, while Token Replacement in Request detokenizes tokens in your outbound request.

​
How It Works

  1. Your system sends an HTTP request to the PCI Booking relay endpoint, specifying the destination URL and including card tokens in the request body.
  2. PCI Booking validates the destination against your account’s allowed endpoints (relay restrictions).
  3. PCI Booking retrieves the real card data for each token and substitutes it into the request body.
  4. The modified request is forwarded to the destination with the real card data.
  5. The destination’s response is returned to your system.

​
Supported Content Types

PCI Booking detects the content type automatically and applies the appropriate replacement engine:

​
Bi-Directional: Tokenization on the Way Back

The same proxy call can also tokenize card data in the destination’s response. If your profile is configured for it, PCI Booking extracts card data from the response, tokenizes it, and returns tokens to you instead of raw card numbers. See Tokenization on Response for details on setting up profiles for this. When tokenization on response is active, the response includes:

​
Two Replacement Modes

There are two ways to tell PCI Booking where the card data goes in your message:
  • Placeholders — embed $~Name~$ placeholders (e.g. $~Number~$, $~ExpirationMM~$, $~CVV~$) directly in the request body where the card values belong. See the full placeholder list. Use placeholders when the content is plain text or any format that is not valid XML or JSON.
  • Target profiles — configure a target profile once per third-party message format and reference it by name. Each profile includes content filters that define where card fields appear in the message, plus optional client certificates for mutual TLS. Use profiles for valid XML, JSON, or query-string messages, and whenever the card data needs manipulation on the way out — expiration date formatting, card type code mapping, substring extraction.
If the destination is a payment gateway, strongly consider using the Universal Payment Gateway instead of token replacement. UPG handles the gateway’s message format, credentials, and error handling for you — token replacement to a gateway means maintaining that integration yourself.

​
Security

  • Relay restrictions. Your account can be configured with an endpoint whitelist. Requests to destinations not on the list are rejected. Contact support or use the Admin portal to manage your allowed endpoints.
  • Client certificates. Target profiles can include client certificates for mutual TLS authentication with the destination.
  • Timeout. Relay requests have a default timeout of 60 seconds.

​
Next Steps

Token Replacement in Response

The reverse direction: third parties send requests to your API through PCI Booking.

File Transfer Token Replacement

Send card data via SFTP/FTPS.

Use Tokens Overview

All detokenization methods.