- Guides
- Proxy Recipes
- API
- Form JS
- External Links
PCI Vault can securely send and receive sensitive payment data on your behalf, allowing your website or application to communicate with Payment Service Providers (PSPs) and other third-party services without bringing PCI-sensitive data into your environment. This helps minimize your PCI DSS scope while maintaining seamless integrations.
The PCI Proxy uses a powerful and flexible templating engine that enables you to transform and map requests to virtually any API or web service. Whether you're integrating with a PSP, payment gateway, or custom endpoint, the proxy can be tailored to match the required request and response formats. If you need any assistance, the PCI Vault development team is available to help you configure and optimize your proxy templates.
Decrypt and send data to a third party, the third party's response will be sent to you via a webhook.
If requests to the third party fails with status 429 or 500 or higher, it will be retried.
The request object will be used to populate the request to the third party. The body property can be any valid mustache template. The keys in the mustache template will be matched back to the JSON object for the given token and populated accordingly.
The reply from the third party will be forwarded to the URL specified in the webhook object.
All URLs must use the HTTPS protocol and have valid SSL certificates.
Requests are asynchronous by default, but when the synchronous parameter is set
to true, it will wait and return the response from the third party directly.
Note: the third party is required to return a result within 20 seconds for synchronous calls. Longer running requests are considered a failure.
The token for the data to be decrypted and sent.
The reference with which the token has been stored, both the reference and the token must be supplied in order to decrypt the associated data.
The identifier for the key used to originally encrypt the data.
The passphrase for the key used to originally encrypt the data.
How many times the request to the the third party will be tried until it succeeds. Every attempt is billable. The default value is 5, the maximum value is 5, and the minimum is 1.
Debug mode returns the populated template as it will be sent to the third party. Debug mode requests are still treated as live requests: the request to the third party will be made and be billed accordingly.
A comma separated list of rule ids to apply to the sent data in order. This does not change stored data. Learn more about the Rule Engine.
Example data presets:
Execute the request synchronously and wait for response.
Make the request originate from a static IP address. Set to true if the third party requires requests to come from one IP address which can be whitelisted.
A webhook to send the asynchronous proxy request result to.
The URL for the webhook. This must be an https URL.
A secret that will be returned in the webhook call's X-PCIVault-Webhook-Secret header.
A value between 1 and 5 for the maximum amount of times the webhook should be called per token update. Calls to the webhook will stop on a 200 HTTP response, or when max_attempts are reached.
Some metadata which will be merged into the webhook response. This is useful for uniquely identifying webhook responses to requests.
Retrieve and encrypt data from a third party, the token will be sent to you via a webhook.
If requests to the third party fails with status 429 or 500 or higher, it will be retried.
All URLs must use the HTTPS protocol and have valid SSL certificates.
Requests are asynchronous by default, but when the synchronous parameter is set
to true, it will wait and return the response from the third party directly.
Note: the third party is required to return a result within 20 seconds for synchronous calls. Longer running requests are considered a failure.
The user for the key to use when storing the third party response.
The passphrase to use when storing the third party response.
The tokenization algorithm to use when storing the third party response.
Set to true to use PCI Vault's smart parse algorithm to interpret the third party response.
The tokenization algorithm to use when storing the third party response.
How many times the request to the the third party will be tried until it succeeds. Every attempt is billable. The default value is 5, the maximum value is 5, and the minimum is 1.
A comma separated list of rule ids to apply to the received data in order. The rules are applied right before the data is stored.
Example data presets:
Execute the request synchronously and wait for response.
Make the request originate from a static IP address. Set to true if the third party requires requests to come from one IP address which can be whitelisted.
A webhook to send the asynchronous proxy request result to.
The URL for the webhook. This must be an https URL.
A secret that will be returned in the webhook call's X-PCIVault-Webhook-Secret header.
A value between 1 and 5 for the maximum amount of times the webhook should be called per token update. Calls to the webhook will stop on a 200 HTTP response, or when max_attempts are reached.
Some metadata which will be merged into the webhook response. This is useful for uniquely identifying webhook responses to requests.
Create a Certificate Signing Request to be used when generating a client certificate for mTLS.
When sending data to, or fetching data from a third party that uses mTLS, the third party will ask for a CSR which they will use to generate a certificate. This certificate can be imported and later used to make requests to the third party. Use the Import Proxy Certificate endpoint to import a certificate.
This endpoint will generate a key pair behind the scenes and embed the public key in the CSR. The private key is stored internally and cannot be retrieved.
Note: The CSR must not be deleted after generating a certificate as it holds the key pair needed to decrypt data from the third party.
A unique id for the CSR. Will be used later to import the actual certificate. If left blank, an id will be generated.
The length of the generated key in number of bits. Allowed values are 2048, 3072 and 4096. Defaults to 2048.
Common Name. This is the fully qualified domain name.
Organization. The official legal name of the company.
Organizational Unit. The internal department managing the certificate.
Locality. The city or town where the company is located.
State or Province. Region where the company resides.
Country. The standard 2 letter code for the location e.g US
List Certificate Signing Requests using this endpoint. You can either fetch a specific CSR by providing its id, or list all of the available ones.
By default the action returns the CSR details with all the domain attributes and the actual data in a JSON object, the new lines in the data are therefore escaped. In order to get the data in text format for easier saving on the file system, pass the download=true query parameter.
The unique id of the CSR when trying to fetch a specific one. If omitted, all CSRs will be listed.
Set to true to download the CSR data only, as text.
# No Body
Delete a specific CSR.
Note: Once deleted, the key pair associated with it also gets deleted. Therefore any certificates generated from the CSR become unusable.
The unique id of the CSR to delete.
# No Body
Import a client certificate to be used for mTLS requests to a third party.
Once a third party has signed the Certificate Signing Request you generated, import the resulting certificate here. The csr_id query parameter must reference the CSR that was used to generate the certificate, so that the imported certificate can be matched with its stored key pair.
The body of the request is the raw PEM encoded certificate data.
Note: The CSR referenced by csr_id must not be deleted, as it holds the key pair needed to use this certificate.
A unique id for the certificate. If left blank, an id will be generated.
The id of the Certificate Signing Request that was used to generate this certificate.
The PEM encoded certificate data.
-----BEGIN CERTIFICATE----- MIIEwjCCAqoCAQAwfTELMAk... -----END CERTIFICATE-----
List client certificates using this endpoint. You can either fetch a specific certificate by providing its id, or list all of the available ones.
By default the action returns the certificate details in a JSON object, the new lines in the data are therefore escaped. In order to get the data in text format for easier saving on the file system, pass the download=true query parameter.
The unique id of the certificate when trying to fetch a specific one. If omitted, all certificates will be listed.
Set to true to download the certificate data only, as text.
# No Body
Delete a specific client certificate.
Note: This does not delete the Certificate Signing Request or key pair used to generate the certificate. To also remove those, delete the corresponding CSR.
The unique id of the certificate to delete.
# No Body
The specifications on this endpoint are subject to change.
If you have a Network Token Requester ID, PCI Vault can assist in requesting and returning network tokens.
The token for the data to be decrypted and sent.
The reference with which the token has been stored, both the reference and the token must be supplied in order to decrypt the associated data.
The identifier for the key used to originally encrypt the data.
The passphrase for the key used to originally encrypt the data.
Your Network Token Requester ID.
A webhook to send the network tokenization result to.
The URL for the webhook. This must be an https URL.
A secret that will be returned in the webhook call's X-PCIVault-Webhook-Secret header.
A value between 1 and 5 for the maximum amount of times the webhook should be called per token update. Calls to the webhook will stop on a 200 HTTP response, or when max_attempts are reached.
Some metadata which will be merged into the webhook response. This is useful for uniquely identifying webhook responses to requests.