How to Tokenize Card Data in Transit and Reduce Your PCI Scope

If you've integrated with third parties such as online travel agencies, channel managers, card issuers or offer merchants the possiblity to authorization a transaction via API, you've probably seen it: a payload arrives, and right there in the JSON or XML is a full card number and CVV in plain text. You didn't ask for it that way. That's just how it works.

As soon as that payload reaches your server, you have a compliance problem. Any system that stores, processes, or transmits raw card data is in scope for PCI DSS, the security standard for card data. That includes the service that parses the request, the database that stores it, the logs that record it, and the queue that passes it along. Every one of them needs stricter controls, more audit work, and more care than the rest of your stack.

Most of the time, your application doesn't need the actual card number. It needs a reference it can store now and use later, when it's time to charge the card or pass it on. That reference is a token.

The Filter Proxy is PCI Proxy's API for exactly this problem, and the name explains how it works. A proxy is a server that sits between two systems and forwards traffic between them. You've likely used one before, such as a reverse proxy in front of your app. The Filter Proxy works the same way, with one addition: as it forwards traffic, it filters out the card data and replaces it with tokens. The sender and your server still exchange messages as usual, but the card data never reaches you.

The use cases

The Filter Proxy is useful whenever card data reaches you from a system you don't control. Three areas come up again and again.

Bookings and reservations

Travel runs on businesses exchanging booking data, and card details often come along with it. Hotels pull reservations from online travel agencies. Airlines and tour operators exchange bookings with agencies and suppliers. Travel SaaS platforms, such as channel managers and property management systems, collect reservations from dozens of sources and pass them on to the businesses they serve. The card is usually there to guarantee the booking, take a deposit, or charge later. With the Filter Proxy in the path, those bookings arrive with tokens in place of card data. That's true whether your system fetches them or the partner sends them to you. Your reservation logic doesn't change, but nothing downstream holds a usable card number.

Virtual cards

If you're building on virtual cards, your issuing partner or card program probably returns full virtual card details when a card is created, for example to pay a supplier or cover a single transaction. You need to store those details and use them later, but holding them yourself pulls your systems into PCI scope. With the Filter Proxy between you and your card partner, each virtual card arrives as a token that you can store, pass between internal services, and use when it's time to pay.

Payments

If you run a payment API, your merchants and partners are likely sending you authorization requests with the full card number and CVV, which means every request puts raw card data on your servers. When the Filter Proxy sits in front of that API, merchant requests go through it first. Card data is tokenized before your code ever sees it, so your routing logic, retries, logging, and reporting all work with tokens instead of card numbers.

When a payment needs to go out to an acquirer or processor, you send the token through PCI Proxy's Forward Proxy, which inserts the real card data on the way out. Your core systems never handle plain card data at any point.

How the Filter Proxy tokenizes card data on the fly

Because it's a proxy, the Filter Proxy sees every message that passes through it and scans each one for sensitive card data, such as card numbers and CVVs.

When it finds card data, the Filter Proxy does three things in a single step:

1. Stores the original values in PCI Proxy's secure vault.
2. Generates a token for each value.
3. Replaces the original data in the message with those tokens.

Everything else in the message stays exactly as it was, including the headers, the structure, and every non-sensitive field. Your parser gets the payload it expects, with tokens where the card number and CVV used to be. Because tokenization happens before the data reaches you, raw card data never touches your servers.

Pull vs. Push: two ways to integrate the Filter Proxy

There are two ways to integrate the Filter Proxy, and the right one depends on who starts the call. The filtering and tokenization is identical in both cases. Only the direction of the traffic changes.

Pull: tokenize card data in partner responses

In a Pull integration, your system starts the call. A typical example is a channel manager fetching the latest bookings from a travel agency on a schedule. Instead of calling the partner directly, you send the request through the Filter Proxy, which passes it on unchanged. The partner responds as usual, and the response comes back through the Filter Proxy, which tokenizes the card data before it reaches you.

The change on your side is small. You point the request at the Filter Proxy and tell it where the request should go next. Your request body, your authentication with the partner, and your response handling all stay the same.

Push: tokenize card data in incoming requests

In a Push integration, your partner starts the call. That might be a travel agency sending each booking as it's made, or a merchant submitting a payment request. You give the partner a unique Filter Proxy endpoint to use instead of your own. The Filter Proxy receives each request, tokenizes the card data, and forwards the filtered request to your original endpoint.

This time, the change is on the partner's side, and it's just as small: they send to a different URL. Your endpoint keeps receiving the same requests it always has.

What your server receives

In both cases, the message you receive matches the original except for the sensitive fields. A card number like 4242 4242 4242 4242 arrives as a token such as AAABcHxr-sDssdexyrAAAfyXWIgaAF40, and the CVV gets a token of its own. Names, addresses, booking details, and every other field arrive unchanged and don't get logged or stored. Your integration keeps working as before, and the real card data stays in PCI Proxy's vault.

For request formats, headers, and code examples, see the Pull and Push guides in the API documentation, or start with the Filter Proxy overview.