Skip to main content
PCI Tokens protect sensitive card payment credentials and keep raw card data out of your systems. This feature gets you out of the PCI compliance hassle in almost no time. Create tokens from a secure session (SAQ-A+) or by importing PAN data (SAQ-D+), depending on your compliance level.

​
Tokenizing Cards

There are two ways to tokenize a payment card, as described in the table below.

​
Using tokenized cards

The cards are stored securely in the Guardian vault. You cannot access the raw card data, but can use the token with other compliant third parties. A typical use-case is to send the card data to a payment service provider (e.g. an Acquirer) for processing.

​
Injection of sensitive data

The endpoint to forward the card data is POST /api/pci/tokens/{id}/forward (see Forward card data for more details).. This feature forwards your request to the third party and will inject the sensitive data on the fly. You define where to put the data using placeholders. The following table shows the available options:

​
Unwrapping data

All injected data will be represented as a string in the payload. If a specific data type is required, such as a numeric representation of the expiry month, the data can be unwrapped and converted back to its original type as needed: {{ expiry_month | unwrap }}

​
HTTP Headers

Guardian forwards all headers from the request, except those it uses internally (e.g. x-api-key). To override these internal headers, you can provide a key-value pair that replaces the original header with your custom value. The following example demonstrates this situation. The call to Guardian requires the API key in the header, but the destination requires a another API key, which uses the same header key. In this case you can use the x-own-header-name and x-own-header-value headers to override the original header.
In the forwarded call, a header x-api-key: 123456... will be set, replacing Guardian’s internal x-api-key header.