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 hussle 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.
SourceComplianceDescription
sessionMin. SAQ-A+Use the Hellgate SDK to capture cardholder data and send it encrypted to the API.
panMin. SAQ-D+Import full card data in exchange for a token when you have the required compliance.

​
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:
PlaceholderDescription
{{ account_number }}The actual full account number of the stored card.
{{ cardholder_name }}The name of the cardholder.
{{ expiry_year }}Four digit year of the expiry date.
{{ expiry_month }}Two digit month of the expiry date.
{{ security_code }}The security code of the card in case it is present.

​
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. 
curl --location
'https://my-cluster-id.on-hellgate.cloud/api/pci/tokens/8744c9ea-a02b-4ae6-875c-b64fc333e3ef/forward' \
--header 'x-api-key: hlg-sbx-9876...' \
--header 'x-own-header-name: x-api-key' \
--header 'x-own-header-value: 123456...' \
...
In the forwarded call, a header x-api-key: 123456... will be set, replacing Guardian’s internal x-api-key header.