A PCI compliant API is not simply an API with HTTPS: it is an interface designed so that the calling system never comes into possession of sensitive payment data. With PCI Proxy EU, the developer integrates PAN tokenization via REST and the PANs remain in the secure vault, outside their perimeter. This architecture reduces PCI DSS scope dramatically and permanently.
What a PCI compliant API is and why it changes everything for developers
An API is considered PCI compliant when the data flow it handles ensures the calling system never processes the PAN in readable form. The most common way to achieve this is server-side tokenization: the card data is sent directly to the provider's vault via a collection form or SDK, and the merchant's backend receives only an opaque token to associate with the customer or order.
This approach has a direct impact on PCI scope. If the backend never receives the PAN, it does not fall within the CDE (Cardholder Data Environment) and does not need to be certified as such. The developer can write payment, refund and recurring charge logic using the token as an identifier, without worrying about encryption, key management or log auditing.
The integration flow: how the proxy works on the API side
Integration with PCI Proxy EU follows a clear pattern. The frontend collects card data via a hosted input component (an iframe or JavaScript SDK), which sends the PAN directly to the PCI Proxy EU endpoint over HTTPS. The vault returns a token to the frontend, which the browser or app passes to the merchant's backend alongside the other order data. From this point on, the backend works only with the token.
When a payment needs to be processed, the backend calls the PCI Proxy EU API with the token and payment instructions. The proxy retrieves the PAN from the vault, passes it to the processor or acquirer, and returns the transaction result. The merchant only sees the authorisation or decline: card data has never passed through their servers.
Authentication, rate limiting and API security
The PCI Proxy EU API uses authentication via API keys with granular scopes: separate keys for tokenization, detokenization and processor calls. Keys must be rotated periodically and must never be exposed in frontend code. Every call is logged and monitored for anomalies, with automatic alerts for unusual patterns such as request bursts or access from unauthorised IPs.
Rate limiting is configurable per merchant and per endpoint, with differentiated policies for test and production environments. The sandbox faithfully replicates production API behaviour, including error responses, allowing the development team to test every scenario before deployment. OpenAPI documentation is available for generating clients in any language.
Frequently asked questions
Do I need to modify my backend to use the PCI Proxy EU API?
Changes mainly concern the frontend, where the card collection form is replaced with the hosted component. The backend requires minor changes: instead of receiving the PAN, it receives the token and uses it in API calls to PCI Proxy EU. Business logic remains unchanged.
Is the API RESTful and does it support webhooks?
The API follows REST conventions with JSON payloads and responds with standard HTTP codes. Webhooks are supported for asynchronous events such as deferred transaction outcomes, 3DS2 challenges and chargeback notifications. Each webhook includes an HMAC signature to verify its authenticity.
How do I test the integration without real cards?
PCI Proxy EU provides a sandbox environment with dedicated test credentials and a set of test cards that simulate success, decline, 3DS2 challenge and timeout scenarios. No real card data passes through the test environment, and no acquirer credentials are required to start developing.
Ready to integrate PCI tokenization without ever touching a PAN? Check the documentation and access the sandbox in minutes. Discover PCI Proxy EU.