API Integration
What Is API Integration in Payments? Definition and How It Works
Definition
API integration in payments is a direct technical connection between a merchant's application and a payment provider's platform, enabling the merchant to control the checkout experience and transaction flow through API calls rather than a hosted redirect.
How it works
In a payments API integration, the merchant's frontend collects payment data, typically card details entered directly into the merchant's own checkout UI, and posts it to the payment provider's API. The API processes the request, returns an authorisation result, and handles subsequent transaction events (capture, refund, void) via the same programmatic interface.
REST APIs are the current standard for payment integrations. Requests and responses are structured in JSON, with authentication handled via API keys or OAuth tokens. Most payment providers also support webhooks to push real-time event notifications back to the merchant's system as transactions progress through their lifecycle.
The primary distinction from a hosted payment page integration is data custody: in a direct API integration, card data passes through or originates on the merchant's systems. This expands PCI DSS scope significantly, the merchant's environment becomes part of the card data flow and is subject to SAQ D or a full QSA audit depending on how data is handled.
Merchants typically use API integration when they need full control over the checkout UX, want to implement custom payment flows (one-click checkout, in-app payments, subscription billing), or require tight integration between the payment event and their own order management or CRM systems.
Why it matters
PCI scope expansion is the main operational trade-off: a direct API integration typically requires SAQ D self-assessment or a QSA audit, compared to SAQ A for a hosted payment page. This adds compliance overhead that must be factored into the integration decision.
Token-based API integrations reduce ongoing PCI exposure: merchants that tokenize card data at the point of collection, using a JavaScript library or SDK that handles raw card data on the provider's behalf, can reduce PCI scope while retaining UX control. This hybrid approach is common at enterprise scale.
API versioning and deprecation creates maintenance risk: payment providers update their APIs, and deprecated versions eventually stop working. Merchants on direct API integrations must budget for ongoing API maintenance and version upgrades.
Direct API access enables advanced capabilities: stored credentials, network tokenisation, retry logic, and custom 3DS flows are typically only available through API integrations, not hosted page options. For merchants optimising approval rates, the API path is usually necessary.
With PXP
PXP's REST API supports the full transaction lifecycle including authorisation, capture, void, refund, and stored credential management. PXP's JavaScript SDK handles card data collection in the browser, reducing PCI scope while keeping the checkout experience on the merchant's domain.
Frequently asked questions
What's the difference between an API integration and a hosted payment page?
An API integration gives the merchant full control over the checkout UI and payment flow, but card data passes through the merchant's environment, expanding PCI scope. A hosted payment page is served by the payment provider; card data never touches the merchant's system, enabling SAQ A compliance. The trade-off is UX control against compliance complexity.
What PCI SAQ type applies to a direct API integration?
It depends on how card data is handled. If the merchant's server receives raw card numbers at any point, SAQ D applies (the most comprehensive self-assessment), or potentially a QSA audit. If the merchant uses a JavaScript-based tokenisation library that handles card data entirely in the browser on the provider's infrastructure, PCI scope is reduced, though not to SAQ A level.
Can API integrations support 3DS and network tokenisation?
Yes, and for merchants focused on approval rate optimisation, API integrations are typically required to access these capabilities. 3DS 2.x integrations need the merchant to pass transaction context data through the API. Network tokenisation is handled via API calls to the token service provider, typically abstracted through the payment provider's API.
How do merchants handle API key security?
API keys should be stored in environment variables or secrets management systems, never hardcoded in application code or committed to version control. Separate keys should be used for test and production environments. Keys should be rotated on a regular schedule and immediately on any suspected exposure. Most providers support IP allowlisting for additional server-side API security.
Revolutionize your business with PXP
Take complete control of your commerce and payments with one platform.
Get Started