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

# UPG vs Token Replacement

> Two ways to send stored card data to a PSP: the Universal Payment Gateway and Token Replacement. How they differ and when to use each.

PCI Booking gives you two ways to deliver stored card data to a payment service provider: the [Universal Payment Gateway (UPG)](/use-tokens/universal-payment-gateway) and [Token Replacement in Request](/use-tokens/token-replacement-in-request). Both keep card data out of your systems, and both will work. For payment processing, **we strongly recommend the UPG**. This page explains why, and when Token Replacement is the better tool.

The fundamental difference in scope: the **UPG is only for PSPs**, while **Token Replacement works with any third-party API** - hotels, OTAs, channel managers, suppliers, and PSPs too. The UPG trades that generality for a far simpler integration when the destination is a PSP.

## How Each One Works

* **UPG**: you send one standardized request (token, amount, operation, PSP credentials) to a single PCI Booking endpoint. PCI Booking builds the full PSP request, inserts the card data, sends it to the PSP, and returns a normalized result.
* **Token Replacement**: you build the destination's request yourself, exactly as its API defines it, with tokens where card data belongs. PCI Booking acts as a transparent proxy: it replaces the tokens with real card data in transit and forwards your request unchanged.

## Comparison

| | Universal Payment Gateway | Token Replacement |
| - | - | - |
| **Destinations** | Supported PSPs only | Any third-party API |
| **Request you build** | One small standardized request, identical for every PSP | The destination's full native request; you own its correctness |
| **Adding another PSP** | Same request - change the gateway name and credentials | A new integration effort per PSP, built and tested by you |
| **PSP changes its API** | PCI Booking updates the integration | You update your request and your replacement profile |
| **Setup in PCI Booking** | None | A replacement profile telling PCI Booking where in the message to insert card data, maintained by you |
| **Response handling** | Normalized statuses (Success / Rejected / TemporaryFailure) with standardized reject reasons | Raw destination response; you parse each format yourself |
| **Payment lifecycle** | Charge, PreAuth, Capture, Void, and Refund linked by transaction reference, plus [fallback routing](/api-reference/process-cards/process-transaction#fallback-routing) across gateways | Whatever you implement yourself |
| **PSP credentials** | Stored securely in PCI Booking, referenced by ID | Included in each request you send |
| **Authentication** | API key | Access token or session token per call |
| **3DS data** | Forwarded to the PSP automatically where supported | You place the ECI/CAVV fields in the request yourself |
| **Troubleshooting and PSP support** | We investigate integration issues on our end, guide you on what to raise with the PSP, and implement changes the PSP recommends | PCI Booking only relays the message; investigating issues with the destination and implementing any changes the PSP recommends is up to you |

## When Token Replacement Is the Right Choice

Token Replacement is the general-purpose tool for delivering card data to **any third party**. Reach for it when:

* **The destination is not a PSP.** A hotel, OTA, channel manager, or supplier API that needs card data inside a booking message can only be served by Token Replacement - the UPG does not apply.
* **Your PSP is not yet among the UPG's integrations.** Use Token Replacement as a temporary stopgap, and at the same time [ask us to add your PSP to the UPG](/use-tokens/universal-payment-gateway#supported-psps) - customers can request new UPG integrations at any point, at no cost. Once the integration is live, switch to the UPG and retire your replacement profile.
* **You need a PSP operation the UPG does not support.** Before building it on Token Replacement, contact [support@pcibooking.net](mailto:support@pcibooking.net) and tell us what you need - we actively enhance the UPG based on what the market needs, and we may be able to add the operation for you.

<Note>
  **Recommendation:** if you are sending card data to a PSP to process a payment, use the UPG. Token Replacement exists for delivering card data to arbitrary third parties; using it for PSP traffic means taking on integration and maintenance work that the UPG already does for you. The choice also determines who can help when something breaks: on the UPG we own the integration, so we can investigate issues on our end, guide the conversation with the PSP, and implement whatever the PSP recommends. On Token Replacement we can only confirm that your message was relayed - everything beyond that is between you and the PSP.
</Note>

## Next Steps

<CardGroup cols={2}>
  <Card title="Universal Payment Gateway" icon="book" href="/use-tokens/universal-payment-gateway">
    Process payments through any supported PSP with one standardized request
  </Card>

  <Card title="Token Replacement in Request" icon="book" href="/use-tokens/token-replacement-in-request">
    Send card data to any third-party API through the relay proxy
  </Card>

  <Card title="Get Payment Gateways" icon="code" href="/api-reference/process-cards/get-payment-gateways">
    Check whether your PSP is already integrated in the UPG
  </Card>

  <Card title="Gateway-Specific Guidance" icon="book" href="/use-tokens/gateway-guidance">
    Per-PSP requirements and capabilities in the UPG
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.