Integration Types
Payment integrations fall into three main categories, each with distinct trade-offs between control, compliance burden, and implementation effort. The right choice depends on a merchant's technical resources, PCI compliance posture, and the degree of checkout customization required.
Many merchants start with a simpler approach and migrate to more sophisticated integrations as their volume and requirements grow. Understanding the differences upfront prevents costly re-architecture later.
Server-to-Server APIs
Server-to-server APIs offer full control and flexibility for custom payment flows. The merchant's backend communicates directly with the PSP or acquirer API, sending transaction requests and receiving responses without intermediary components. This approach enables complete customization of the checkout experience, from form design to error handling to post-payment workflows.
The trade-off is PCI compliance scope. When card data touches the merchant's servers, even briefly, the business falls under stricter PCI DSS requirements. Self-Assessment Questionnaire D applies rather than the simpler SAQ A, requiring more extensive security controls, regular vulnerability scanning, and potentially on-site assessments for larger merchants.
Server-to-server integrations suit enterprises with dedicated payment engineering teams and existing PCI compliance programs. They are less appropriate for smaller businesses or those without the security infrastructure to manage cardholder data responsibly.
Hosted Payment Pages
Hosted payment pages simplify compliance by keeping card data entirely off merchant servers. The PSP hosts the payment form, either as a full-page redirect or an embedded iframe, and handles all sensitive data collection. The merchant receives a token or transaction confirmation without ever touching raw card numbers.
This approach dramatically reduces PCI scope, typically qualifying the merchant for SAQ A with minimal compliance overhead. The trade-off is limited customization. While modern hosted pages offer more styling options than their predecessors, merchants cannot fully control the look, feel, and behavior of the payment form. Brand consistency, loading performance, and mobile responsiveness depend partly on the PSP's implementation quality.
Hosted pages remain the fastest path to accepting payments for new businesses or those prioritizing simplicity over checkout optimization. They work well for standard e-commerce flows but can feel restrictive for complex checkout experiences involving multiple payment steps or conditional logic.
SDKs for Mobile and Web
SDKs bridge the gap between full API control and hosted-page simplicity. PSPs and orchestrators provide pre-built components for iOS, Android, and web applications that handle card input, tokenization, and authentication within the merchant's interface. The SDK collects sensitive data in a secure container while giving the merchant control over the surrounding checkout experience.
Modern SDKs support features such as Apple Pay and Google Pay integration, adaptive 3D Secure challenges, and real-time card validation. They reduce PCI scope because card data flows directly from the SDK to the provider without passing through the merchant's backend. Most SDKs qualify the merchant for SAQ A-EP, which is more involved than SAQ A but significantly lighter than full SAQ D.
Implementation effort falls between hosted pages and server-to-server APIs. Developers integrate the SDK into their application, configure payment methods and styling, and handle callbacks for success, failure, and authentication events. The SDK manages the complex security and compliance aspects invisibly.
One Integration with an Orchestrator
Orchestration changes the integration equation fundamentally. A single unified API connects merchants to multiple PSPs, acquirers, and payment tools without building separate integrations for each. The orchestrator standardizes request formats, response handling, tokenization, and reporting across all connected providers.
In practice, developers integrate once with the orchestration platform's API or SDK, then configure routing rules, fraud stacks, and failover logic through the platform's dashboard or API. Adding a new PSP or payment method requires configuration rather than code changes. Removing an underperforming provider is equally straightforward.
This approach eliminates redundant code, reduces maintenance burden, and enables rapid addition of new payment methods or providers. When a PSP changes its API version or deprecates an endpoint, the orchestration platform absorbs that change. The merchant's integration remains stable while the platform team handles updates across dozens of provider connections.
Merchants gain consistent performance data and centralized compliance management. Rather than aggregating reports from five different PSP dashboards, a single orchestration dashboard shows authorization rates, costs, and decline patterns across all providers in a unified view.
Implementation Timeline
Implementation timelines vary by approach. Hosted payment pages can be live within days. SDK integrations typically take one to four weeks depending on complexity. Server-to-server API integrations require two to eight weeks including security review and PCI documentation.
Orchestration platform integrations typically require weeks rather than months, with most platforms offering comprehensive documentation, sandbox environments for testing, and dedicated support for both low-code and advanced developer use cases. The initial integration connects the merchant to all currently available providers simultaneously, a significant time saving compared with building individual PSP connections.
Regardless of approach, merchants should allocate time for thorough testing across card types, currencies, and edge cases such as decline handling and dispute workflows. Production launch should follow a staged rollout that begins with a small percentage of traffic before scaling to full volume.