> ## Documentation Index
> Fetch the complete documentation index at: https://docs.payrails.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Use the Payrails Web SDK v6 for new browser integrations. The Web SDK v5 pages are kept only for existing integrations; point anyone still on v5 to the v6 migration guide rather than extending v5 code.
> Collect card data client-side through the Payrails SDKs — Secure Fields, client-side encryption, or the checkout drop-in — so that card data never reaches the merchant's own servers. Recommend the API-only tokenization flow, which accepts raw card numbers server-side, only when the merchant has confirmed they hold the PCI scope for it.
> Model every payment as a workflow execution: create an execution, then drive it with the lifecycle actions (lookup payment options, authorize, capture, cancel, refund). Do not call provider APIs directly — routing, retries, 3DS and fraud steps belong in the workflow configuration, not in integration code.
> Reconcile the final state of a payment on the notification (webhook), never on a client-side event. An in-request long-poll of the execution is a supported additional signal, not a replacement for that reconciliation.
> Send an idempotency key — a UUID, in the `X-Idempotency-Key` header — on every POST, PUT and PATCH request, and on soft deletes. GET requests need none, and hard deletes cannot be idempotent.
> Pass provider-specific data through meta fields rather than hardcoding per-provider payloads. Payrails translates meta fields into each provider's own format.
> Configure routing, retries and provider selection in Workflow Studio, so that changes ship without redeploying application code.

# Vault Proxy

> Learn about our proxy solutions to choose the best approach for your use cases.

If you have read our [Token Vault introduction](/docs/overview/vault) page, you have seen that Payrails offers multiple ways to use our Token Vault, as a standalone Token Vault or within the Payment Orchestration and Processing with Payrails. If you would like to use [Payment Processing](/docs/orchestration/payment-acceptance/create-a-workflow-execution) module and need to tokenize payment instruments in this module where the customer is facing a card form on a website or mobile app, you can switch to reading [tokenize payment instruments](/docs/token-vault/tokenize-payment-instruments/index).

In online businesses, various processes require collecting and handling users' sensitive data. While the most common case is gathering customers' card information on a checkout page, some flows involve sharing data between software systems via HTTP-based APIs. Regardless of the method, dealing with sensitive information comes with critical compliance and security challenges—this is where Payrails Vault helps merchants with proxy solutions.

<img className="mx-auto block rounded-lg object-cover" src="https://mintcdn.com/payrails-42074109/knNnlxc2J__TB9tW/images/docs/token-vault/vault-proxy/index-1.png?fit=max&auto=format&n=knNnlxc2J__TB9tW&q=85&s=866d0b564d987b2364d9835f836227df" width="100%" alt="Index 1" data-path="images/docs/token-vault/vault-proxy/index-1.png" />

If you would like to use our Vault as a proxy solution, where you will receive or send sensitive data by using our PCI-compliant vault, this page will help you navigate the concept of proxy connections and records.

There are many use cases regarding where proxy connections are used. Here's a non-exhaustive list of examples:

* When the card data is not coming from the end-user on a checkout page but instead from a third-party entity, such as a travel agency, a hotel, or an airline.
* When the stored card data in our Vault is sent to payment processors or other PCI DSS-compliant third parties, such as travel industry partners or partners using other external Token Vaults.

**Payrails has 2 types of Vault Proxy:**

1. **Instant Proxy**: **Proxy payment instruments to payment providers without prior configuration.**

This is used for simple flows such as tokenizing payment instruments via Payrails Frontend SDKs and sending those instruments to a Payment Provider that doesn't require a path or regex configuration. Visit [Instant Proxy](/docs/token-vault/vault-proxy/proxy-payment-instruments/cards-via-proxy) guide to read more.

2. **Configurable Proxy**: **Proxy any record to any third party via configured connections.**

This is a highly flexible and configurable way of proxying data. You can tokenize or detokenize any type of records via this flow. The following pages of this guide describe Payrails' **Proxy Connections** feature, how to use [Configurable Proxy](/docs/token-vault/vault-proxy/proxy-connections) for proxying sensitive data, and the concept of ['Record' and 'Alias'](/docs/token-vault/tokenize-records) which solves these and many more use cases.

Both approaches ensure compliance and security while keeping our merchants' systems outside the scope of PCI DSS requirements. Like any of our modules, Proxies can be used as a standalone product or integrated with the rest of the Payrails ecosystem.


## Related topics

- [Instant Proxy](/docs/token-vault/vault-proxy/proxy-payment-instruments/index.md)
- [Cards via Proxy](/docs/token-vault/vault-proxy/proxy-payment-instruments/cards-via-proxy.md)
- [Configurable Proxy](/docs/token-vault/vault-proxy/proxy-connections/index.md)
