Skip to main content
The Universal Payment Gateway (UPG) is PCI Booking’s single API endpoint for processing payments. You specify which PSP to use by providing your gateway credentials, and PCI Booking detokenizes the card and sends the transaction to that PSP. Over 100 PSPs are supported.

​
How It Works

The UPG provides a unified request structure that is the same regardless of which PSP you are processing with. You send one standard request with a card token, amount, currency, and your PSP credentials. PCI Booking handles everything from there: it detokenizes the card, constructs whatever API calls the specific PSP requires, and returns a standardized response in a consistent format regardless of which PSP processed the transaction.
  1. You send a standard request to the UPG endpoint with the card token, transaction details, and PSP credentials.
  2. PCI Booking detokenizes the card, replacing the token with real card data.
  3. PCI Booking translates your request into the PSP-specific format and sends all necessary API calls to complete the operation.
  4. PCI Booking normalizes the PSP’s response into a standardized format and returns it to you.
Your systems never touch card data. You integrate once with PCI Booking and work exclusively with tokens. PCI Booking handles the individual integrations with each PSP.

​
Providing PSP Credentials

You can provide your PSP credentials in two ways:
  • Inline. Include the PSP name and credential key-value pairs directly in the request body. Useful for testing or when credentials vary per transaction.
  • Stored credentials. Pre-save your PSP credentials via PSP Credentials and pass a credentialsId query parameter. Recommended for production use.

​
Supported Operations

The Tokenize operation does not trigger any charge, and the card remains stored in PCI Booking as well - if you no longer need the PCI Booking token after gateway tokenization, consider deleting it.

​
Testing in Sandbox

When your PCI Booking account is a sandbox account, UPG transactions are automatically routed to the payment gateway’s own sandbox/test environment. The gateway credentials you store must therefore be sandbox credentials from your PSP. To test the flow without any PSP account, use PCI Booking’s built-in test gateways instead - see Testing and Going Live.

​
Transaction Result Statuses

Every UPG operation returns one of these result statuses:

​
3D Secure and the UPG

You don’t need to do anything special to use 3DS with the UPG. If a token has stored 3DS authentication data (from the hosted card form, store-3d-token, or an in-transit tokenization - see 3DS Auth Management) and the PSP integration you’re routing to supports receiving it, PCI Booking includes that 3DS data in the charge request automatically.
It is your responsibility to make sure a token actually has 3DS data before charging it through a PSP that requires 3DS. PCI Booking does not retroactively add 3DS to a token that lacks it - if the token was created without 3DS (for example, UnavailThreeDSAuth defaulted to Accept), the charge will simply be rejected by any PSP that mandates 3DS. Use Retrieve Token Metadata or 3DS Auth Management to check beforehand.
Not every PSP integration supports receiving 3DS data - check Gateway-Specific Guidance for your PSP.

​
Cardholder Name

The cardholder name on a token is sent to the PSP exactly as it was captured - PCI Booking does not reformat, split, or otherwise adjust it. If your PSP has specific requirements for the name (e.g. separate first/last name fields, a minimum length, or a particular character set), make sure those requirements are satisfied at capture time, not at charge time - there’s no way to correct the name later without a new token.

​
Supported PSPs

See the full list of supported PSPs on our website, or query Get Payment Gateways for the definitive, programmatic list along with each gateway’s capability flags (3DS, gateway tokenization, network tokenization, partial refund support) and required credential fields. If your PSP is not listed, we can add it. Contact support@pcibooking.net with:
  • Your PCI Booking username.
  • The PSP’s server-to-server API documentation (in English).
  • If you need 3DS with this PSP: their documentation for submitting an externally-obtained 3DS authentication result (CAVV/ECI/XID), if PCI Booking will not be running 3DS itself for this integration.
  • A test account or instructions on how to set one up.
  • A support contact at the PSP.
If your PSP requires whitelisting the origin of incoming requests, see Outbound IP Addresses.

​
Key Benefits

  • One endpoint, 100+ PSPs. The same API call works for Stripe, Adyen, Worldpay, and any other supported PSP.
  • Zero PCI scope. Card data never passes through your infrastructure.
  • PSP portability. Switch processors by changing your gateway credentials ID, not your integration code.
  • Consistent interface. PCI Booking normalizes request and response formats across all PSPs.

​
Next Steps

Charge

Process a simple charge transaction.

Authorize & Capture

Split authorization and capture into two steps.

PSP Credentials

Set up and manage your PSP credentials.

Gateway-Specific Guidance

PSP-specific requirements and configuration.