Shopping Internet Digital Connection Networking Concept
The choice between hosted checkout and API checkout shapes how a payment stack handles every transaction. It determines PCI compliance burden, conversion potential, branding flexibility, mobile experience, how quickly new payment methods can be added, and whether the merchant can route across multiple PSPs without rebuilding. For enterprise merchants, the decision is also rarely binary, with most production payment stacks ending up using a combination of integration methods for different surfaces and transaction types.
Learn the five practical integration patterns merchants choose between in 2026 (hosted checkout, hosted fields, full API, mobile SDK, and payment links), compare them across every dimension that matters, to make a decision framework based on merchant profile, technical capacity, and business priorities. The framing throughout assumes a multi-PSP, orchestration-aware payment stack rather than a single-provider integration, because that is increasingly the architecture that most enterprise merchants operate under.
Before the deeper analysis, the short version of each option:
The choice is not strictly between “hosted” and “API.” Modern payment stacks combine these patterns based on which surface the transaction is happening on, which PSP will process it, and what the business priorities are at that touchpoint.
A hosted checkout solution sends the customer to a payment page hosted on the PSP’s or orchestration platform’s infrastructure. The merchant’s site redirects to the hosted page, the customer completes payment there, and the customer returns to the merchant’s site after the transaction is finished or canceled.
The merchant never sees or stores card data. The PCI compliance burden is mostly absorbed by the PSP or platform, which means the merchant typically qualifies for a simpler PCI Self-Assessment Questionnaire (SAQ A) rather than a full PCI DSS audit. Setup time is hours to days for most platforms, and the integration is usually configuration-driven rather than code-heavy.
Where hosted checkout works well:
The limitations of hosted checkout:
For a deeper view of how to optimize the checkout experience regardless of integration model, see Gr4vy’s guide on checkout optimization strategies.
A full API integration uses REST APIs, server SDKs, and client-side JavaScript to build the entire payment flow inside the merchant’s environment. The customer never leaves the merchant’s site, no redirect happens, and every pixel of the payment experience is under the merchant’s control.
The trade-off is responsibility. With full API integration, card data flows through the merchant’s infrastructure, which means the merchant typically operates under PCI DSS SAQ D requirements (the most comprehensive Self-Assessment Questionnaire) and must maintain a PCI Level 1 compliant environment if transaction volumes exceed scheme thresholds. The compliance overhead is significant, with annual costs that can run from $100,000 to several hundred thousand dollars for enterprise merchants.
Where API checkout works well:
The limitations of full API checkout:
Most articles compare hosted checkout to full API integration as if those were the only two choices. There is a third option that combines most of the advantages of each: hosted fields.
A hosted fields integration embeds secure iframes inside the merchant’s own checkout page, with each iframe controlled by the PSP or vault provider. The customer sees what appears to be the merchant’s checkout page, but the actual card-number, expiration, and CVV inputs are running inside iframes hosted on the PSP’s domain. Card data flows directly from the customer’s browser to the PSP, never touching the merchant’s servers.
The result is PCI scope reduction similar to a hosted page (SAQ A in most implementations) combined with branding control similar to a full API integration. The customer never sees a domain change. The merchant designs the checkout page exactly as they want it. The card-input fields look and feel native to the merchant’s brand, with only the PSP-controlled inputs being technically separate.
Where hosted fields work well:
The trade-offs:
For merchants in the middle of the size and complexity spectrum, hosted fields is often the strongest answer and is increasingly the default pattern enterprise orchestration platforms recommend.
A separate but related question is how to handle payments inside native mobile apps. Three options exist: redirect to a hosted page via a web view, embed hosted fields via a web view, or use a native mobile SDK provided by the PSP or orchestration platform.
Mobile SDKs are designed specifically for in-app payment collection. They provide native iOS and Android components that match platform design conventions, integrate with biometric authentication (Touch ID, Face ID, fingerprint), handle Apple Pay and Google Pay natively, and avoid the web-view friction that hosted pages create on mobile.
Where mobile SDKs are essential:
The compliance posture of mobile SDKs varies by implementation. Most modern mobile SDKs from major orchestration platforms keep card data inside the SDK’s secure context, avoiding direct exposure to the merchant’s app code, which maintains a reduced PCI scope similar to hosted fields.
For a deeper look at mobile-specific patterns, see Gr4vy’s guide on mobile checkout best practices.
The fifth integration pattern is payment links, which are shareable URLs that route to a pre-configured payment page. The merchant generates a link through an API or dashboard, sends it via email, SMS, chat, or any other channel, and the recipient completes payment when they choose.
Payment links work alongside hosted checkout and API integration rather than replacing them, handling the cases where a traditional checkout flow does not fit:
Industry data suggests payment links can unlock 7% or more additional revenue for merchants who add them to their stack, by serving transaction scenarios that traditional checkout patterns cannot address. They are also the simplest integration path: a single API call generates a fully functional payment page.
The five integration patterns across every dimension that matters for a merchant evaluation:
| Dimension | Hosted checkout | Hosted fields | Full API | Mobile SDK | Payment links |
|---|---|---|---|---|---|
| Customer experience | Redirect to PSP page | Stays on merchant site, fields in iframes | Fully native to merchant site | Native in-app | Recipient-driven, asynchronous |
| PCI scope | SAQ A (minimal) | SAQ A (minimal) | SAQ D (full) | SAQ A typically | SAQ A (minimal) |
| Branding control | Limited | High | Full | Native to platform | Configurable, PSP-hosted |
| Time to deploy | Hours to days | 1-3 months | 3-6 months | 1-3 months | Hours |
| Engineering effort | Low | Medium | High | Medium-High | Very low |
| Conversion potential | Lower (redirect friction) | High | Highest | Very high in-app | High for fit use cases |
| Multi-PSP routing | Requires orchestration | Yes, via orchestration | Yes, requires routing layer | Yes, via orchestration | Yes, via orchestration |
| Mobile experience | Acceptable | Good (with mobile-optimized fields) | Good | Best | Excellent (recipient device-native) |
| Apple Pay / Google Pay | Limited customization | Yes | Yes | Native | Yes |
| Custom payment flows | Limited | Possible | Full flexibility | Full flexibility | Limited to single transactions |
| 3D Secure handling | Managed by PSP | Managed by PSP | Merchant-implemented | Managed by SDK | Managed by PSP |
| Best for | Fast launch, low-volume, simple flows | Most enterprise checkouts | Complex platforms, marketplaces | Mobile-first businesses | Invoicing, B2B, async commerce |
The pattern that emerges from the table: hosted fields is the strongest default for most enterprise merchants, with mobile SDK for native app surfaces, payment links for asynchronous use cases, and full API only where the complexity genuinely justifies the overhead.
Choose hosted checkout when one or more of these apply:
Choose full API integration when one or more of these apply:
For most enterprise merchants, hosted fields is the right default. Choose this pattern when:
The choice between hosted, hosted fields, and full API is often presented as a one-time decision tied to a specific PSP. With payment orchestration, the framing changes meaningfully.
An orchestration layer sits between the merchant’s checkout (whatever its integration model) and the underlying PSPs. The merchant can implement hosted fields once through the orchestration platform, and the platform routes the resulting transactions across multiple PSPs based on configurable rules. The integration model becomes a property of the merchant’s checkout, decoupled from the PSP relationships sitting underneath.
This is meaningful in three ways:
1. Integration choice is no longer locked to PSP choice. A merchant can use hosted fields with Stripe and Adyen simultaneously, with the orchestration platform deciding which PSP processes each transaction. Switching providers does not require rebuilding the checkout.
2. Different integration models can coexist. The web checkout might use hosted fields, the mobile app might use a mobile SDK, and the B2B invoicing might use payment links. All three run on the same underlying PSP relationships and the same routing rules.
3. Migration paths become smoother. A merchant that starts with hosted checkout can migrate to hosted fields without changing their PSP relationships. A merchant on hosted fields can selectively migrate to full API for specific transaction types without rebuilding everything.
This is the architecture Gr4vy’s Checkout product was built around. Hosted checkout, hosted fields, REST APIs, mobile SDKs, plugins, and payment links all sit on top of the same orchestration platform, with routing logic that connects to more than 400 PSPs and payment methods through a single integration.
The PCI compliance burden differs significantly across integration patterns, and the differences directly affect operational cost and audit complexity.
SAQ A is the simplest Self-Assessment Questionnaire. It applies when the merchant fully outsources cardholder data handling to a PCI DSS-validated third party, with the merchant’s own systems never seeing, processing, or transmitting card data. Hosted checkout, well-implemented hosted fields, payment links, and most mobile SDKs qualify for SAQ A. The annual compliance overhead is typically a few thousand dollars and a couple of weeks of internal work.
SAQ A-EP applies when the merchant’s website or mobile app affects the security of the payment page, even though the merchant does not directly handle card data. Some hosted fields implementations fall into this category if the integration code is not isolated from sensitive elements. The compliance burden is higher than SAQ A but still significantly less than SAQ D.
SAQ D is the most comprehensive Self-Assessment Questionnaire, applicable when the merchant directly handles, processes, or transmits cardholder data. Full API integrations almost always fall into SAQ D. The annual compliance cost is meaningful, typically $100,000 to several hundred thousand dollars for enterprise merchants, plus the operational overhead of maintaining a PCI Level 1 compliant environment.
PCI DSS 4.0.1 (the current standard) tightened several requirements around stored card data, third-party script integrity, and authentication. Merchants who operated under SAQ D in 2024 should reassess whether their current architecture still represents the most efficient PCI posture, because the gap between SAQ A and SAQ D has widened. For a deeper view, see Gr4vy’s analysis of PCI DSS compliance and payment orchestration.
Most merchants do not stay on the integration they started with. The typical evolution looks like:
Stage 1: Hosted checkout (years 0-2). Fast launch, simple needs, limited engineering capacity. Most merchants begin here.
Stage 2: Hosted fields (years 2-5). As volume grows, the branding limitations and conversion impact of redirect become measurable. Migrating to hosted fields preserves PCI scope reduction while recovering UX control.
Stage 3: Hosted fields plus mobile SDK (years 3-7). Mobile share of revenue grows, and the in-app experience becomes a meaningful conversion driver. Adding a mobile SDK alongside the web hosted fields integration becomes standard.
Stage 4: Hosted fields plus mobile SDK plus payment links (years 4+). B2B, social, voice, and agentic use cases emerge. Payment links handle the asynchronous and non-traditional checkout scenarios that the rest of the stack cannot address.
Stage 5: Selective full API (years 5+, only where justified). Complex payment flows that hosted fields cannot express get migrated to full API. This is rarely a wholesale migration; instead, specific transaction types move to API while the bulk of the volume remains on hosted fields.
The merchants who manage this evolution best are the ones who started with an orchestration platform from the beginning, because the platform decouples the integration model from the PSP relationships and makes each migration step a configuration change rather than a rebuild.
A handful of patterns separate well-implemented payment stacks from troubled ones:
Choosing full API integration too early. The PCI compliance overhead is significant, and the engineering team that ships the integration is often not the team that has to maintain it long-term. Most merchants under $20M in annual card volume do not yet need the level of control that full API provides, and the operational drag becomes a problem before the strategic value materializes.
Locking the integration model to a single PSP. A hosted page implementation tied to one PSP becomes a multi-month rebuild when the merchant wants to add or switch providers. Implementing through an orchestration platform from the start preserves the flexibility to add PSPs without rebuilding the integration.
Treating mobile as a secondary surface. In most B2C categories, mobile is the majority of revenue. Implementing a web-only integration first and adding mobile later typically produces a worse mobile experience than building mobile-native from the start. The order of priority should reflect where revenue actually comes from.
Skipping hosted fields and going straight from hosted to full API. Many merchants overshoot. The full API integration produces more flexibility than they need, with more PCI scope and engineering overhead. Hosted fields is the right destination for most enterprise checkouts, and the migration from hosted page to hosted fields is significantly faster than the migration from hosted page to full API.
Underestimating the ongoing maintenance burden. Payment integrations are not one-time projects. APIs evolve, security requirements tighten, new payment methods emerge, and the integration has to evolve with them. The team needs to be sized for ongoing maintenance over the long term, with initial implementation being only the first phase of a continuous commitment.
Combining merchant profile with integration choice produces the following starting recommendations:
| Merchant profile | Recommended integration | Why |
|---|---|---|
| Small or new business (under $1M annual card volume) | Hosted checkout | Fast launch, lowest overhead, focus engineering on product |
| Growing mid-market merchant ($1-20M) | Hosted checkout, planning migration to hosted fields | Capture volume now, plan UX investment when conversion impact becomes measurable |
| Enterprise ecommerce ($20M-$1B) | Hosted fields plus mobile SDK | Best balance of UX, PCI, and flexibility |
| Mobile-first enterprise | Mobile SDK plus hosted fields for web | Match the surface where revenue concentrates |
| Marketplace or platform | Full API where complexity demands it, hosted fields elsewhere | Complex payment flows require code-level control |
| B2B with invoicing | Hosted fields plus payment links | Match the buying patterns of B2B customers |
| Subscription business | Hosted fields plus mobile SDK plus payment links | Cover web, app, and recovery flows |
| Agentic commerce participant | Full API for agent surfaces, hosted fields for human surfaces | Protocol-level integration requires direct API access |
These are starting points to guide further evaluation. The actual decision depends on the specific business priorities, the team’s capabilities, and the existing payment infrastructure. Many enterprise merchants operate combinations of these patterns simultaneously, with each transaction routed through whichever integration best fits the customer surface and the merchant’s priorities at that touchpoint.
Hosted checkout redirects the customer to a payment page hosted on the PSP’s or orchestration platform’s infrastructure, with the merchant never touching card data. API checkout uses REST APIs and SDKs to handle the entire payment flow inside the merchant’s environment, with the merchant taking on full responsibility for the payment UX and PCI compliance. Hosted checkout is faster to deploy and has lower PCI scope; API checkout offers maximum control and branding flexibility.
API checkout typically achieves higher conversion because customers stay on the merchant’s site throughout the payment process, avoiding the trust friction that a domain change introduces. Industry research suggests approximately 70% of checkout abandonment stems from trust concerns during transitions, making the redirect in hosted checkout a measurable conversion cost. However, well-implemented hosted fields (a hybrid pattern) achieve conversion close to full API while keeping PCI scope similar to hosted checkout.
Yes, the terms are used interchangeably. Both refer to a payment page hosted on the PSP’s or orchestration platform’s infrastructure, with the customer redirected from the merchant’s site to complete the transaction.
Hosted checkout typically allows merchants to qualify for PCI DSS SAQ A, the simplest Self-Assessment Questionnaire, because card data never touches the merchant’s systems. API checkout almost always requires SAQ D, the most comprehensive Questionnaire, because the merchant directly handles cardholder data. The annual compliance overhead can differ by an order of magnitude, with SAQ A typically costing a few thousand dollars and SAQ D often costing $100,000 or more for enterprise merchants.
Hosted fields are secure iframes embedded inside the merchant’s own checkout page, with each iframe controlled by the PSP or vault provider. Customers see what appears to be the merchant’s checkout, but the actual card-input fields are technically hosted on the PSP’s domain. The pattern combines PCI scope reduction similar to a hosted page with branding control similar to full API integration, which is why it is increasingly the default for enterprise checkouts.
Yes, and most merchants do. The typical evolution is from hosted checkout to hosted fields to selective full API, with mobile SDKs and payment links added along the way. The migration is significantly easier if the merchant started with an orchestration platform, because the underlying PSP relationships do not need to change when the integration model evolves.
Not necessarily. Both patterns can support the same payment methods; the difference is how the merchant configures them. Hosted checkout often includes a pre-built selection of methods that the PSP supports, making international expansion faster. API checkout requires the merchant to integrate each method individually, which produces more flexibility but slower time-to-market for new methods.
Hosted checkout typically deploys in hours to days. Hosted fields integrations take 1-3 months. Full API integrations take 3-6 months for a comprehensive implementation. Mobile SDK integrations take 1-3 months. Payment links can be live in hours.
No, the two are equally secure when properly implemented. Both rely on tokenization, encryption, and the underlying PSP’s security infrastructure. The PCI scope is different (hosted checkout reduces the merchant’s compliance burden) but the actual security posture of a well-implemented integration in either model is comparable.
Yes, and this is the most common pattern for enterprise merchants. Web checkout might use hosted fields, the mobile app might use a mobile SDK, B2B invoicing might use payment links, and complex marketplace transactions might use full API. An orchestration platform makes this practical because the underlying PSP relationships and routing rules are shared across all the integration surfaces.
Hosted fields are a specific implementation of iframes for payment-input collection. The terms are sometimes used interchangeably, but “hosted fields” usually refers specifically to the pattern where individual card-input fields are isolated in iframes inside an otherwise merchant-controlled checkout page. Other iframe patterns exist (full-page iframe checkouts, redirect iframes) and have different trade-offs.
Neither, exactly. Mobile SDKs are a separate integration pattern designed for in-app collection. Most modern mobile SDKs keep card data inside the SDK’s secure context (avoiding direct exposure to the merchant’s app code), which preserves PCI scope similar to hosted fields, while providing the native in-app experience that web-view-based hosted pages cannot match.
No, they work as a complementary capability. Payment links handle asynchronous and non-traditional payment scenarios (invoicing, social commerce, voice, agentic flows) that traditional checkout patterns cannot serve. Most merchants who add payment links use them alongside their primary checkout to extend reach into new transaction types.
The hosted vs API choice is less binary than most articles present it. The realistic question for most enterprise merchants is which combination of integration patterns best serves which transaction surface, with hosted fields as the default for most web checkouts, mobile SDK for native apps, payment links for asynchronous and B2B scenarios, and full API reserved for the specific cases where complex payment flows justify the overhead.
The architectural decision that matters most is whether all of these integration surfaces share the same underlying PSP relationships and routing rules. Merchants who run each integration on its own dedicated PSP integration multiply their operational complexity, fragment their analytics, and lock themselves into multiple parallel vendor relationships. Merchants who run their integrations on top of an orchestration platform share PSP relationships, share routing logic, and share analytics across every customer surface.
If you’re evaluating which integration pattern fits your current stack or thinking about evolving from hosted checkout to hosted fields, mobile SDK, or any other surface, contact our team for a walkthrough of how Gr4vy’s Checkout product supports all five integration patterns through a single orchestration platform.
PSD3 and the Payment Services Regulation (PSR) are the most significant overhaul of European payments…
3D Secure 2 (3DS2) is the authentication protocol that decides whether most of your card-not-present…
Integration gives merchants direct access to global acquiring through orchestration, with control over routing, authentication,…
Every card transaction is classified by the card networks as either customer-initiated (CIT) or merchant-initiated…
Peak moments don’t break systems by accident. They expose the limits that were always there.…
Mastercard is changing how transactions are tracked across the payment lifecycle. The Transaction Link Identifier…