Technioz Team
Editorial
A hosted payment gateway is a checkout solution where the payment provider hosts the payment page, keeping card data off the merchant's servers and significantly reducing PCI compliance scope. Hosted gateways accounted for 58.3% of global payment-gateway revenue in 2025, according to Grand View Research's payment gateway market analysis.
That market position reflects a practical business choice, not just a technical trend. Merchants use hosted checkout to launch payments without building card-entry infrastructure, managing a card-data vault, or owning every security control around payment capture. The trade-off is equally practical: you give up some control over the checkout experience, and PCI responsibility doesn't disappear completely.
Table of Contents
- What Is a Hosted Payment Gateway
- How Hosted Checkout Flows Work
- Pros and Cons of Hosted Payment Gateways
- Hosted vs Direct vs Hybrid Payment Integration
- PCI Compliance and Security Requirements
- Choosing and Migrating to a Hosted Payment Gateway
What Is a Hosted Payment Gateway
A hosted payment gateway moves payment capture to a page operated by a payment service provider, or PSP. The customer enters card or alternative payment details in that provider-controlled environment. After authorization, the gateway returns the customer to the merchant's website or app and reports the payment result, while the merchant avoids handling the raw card number.
The merchant still owns the order and payment state. Its server creates a checkout session, receives a temporary URL or session reference, and sends the customer to the provider. The provider collects payment details, applies fraud controls, and may manage authentication. After checkout, the provider redirects the customer and can send a server-to-server notification. The merchant's backend should verify that result before marking an order paid, shipping goods, or activating access.
This separation reduces the systems that directly touch card data, but it does not remove every compliance task. PCI DSS v4.0.1, which took effect in 2025, makes current control requirements and third-party responsibilities part of the integration decision. A hosted gateway can reduce scope, yet the merchant still needs to secure its own application, manage redirects and webhooks, control access, and document how payment data moves through the system.
Market estimates show why this model remains common. One estimate reports a 52.3% share and USD 17.1 billion in hosted-gateway revenue for 2025 in Grand View Research's market coverage. The figure does not make hosted checkout automatically suitable. Country coverage, payment methods, settlement timing, recurring billing, refunds, dispute handling, and the provider's compliance model determine whether it works in production.
The approach fits small businesses, SaaS companies, marketplaces, and retailers that want payment acceptance without operating card-entry infrastructure. Teams evaluating options should compare payment gateways for SaaS against the checkout control, reporting, integration effort, and compliance responsibilities they can support.
How Hosted Checkout Flows Work
Hosted checkout usually appears in one of two forms. The first is a full-page redirect. The second uses a hosted form, modal, or iframe that keeps more of the visual experience on the merchant's site while the provider controls the sensitive payment fields.
Redirect checkout
A redirect flow starts on your product or cart page. When the customer selects Pay, your backend creates a checkout session and receives a temporary URL or session reference. The browser then leaves your site and loads the provider's payment page.
The provider handles the card form, payment method selection, fraud screening, and any required authentication. Some hosted implementations can also handle 3D Secure, including deciding whether authentication is needed, collecting device information, displaying a challenge, and passing the authentication result into authorization through the Mastercard Gateway hosted 3DS documentation.
After completion, the provider redirects the customer to your result page. Your backend shouldn't trust the browser redirect by itself. It should verify the transaction through a signed callback, webhook, or server-side status request before releasing goods or activating a subscription.
Iframe or hosted-field checkout
An iframe flow keeps the customer on your domain while the payment form appears inside an embedded provider-controlled frame. In some designs, the provider hosts all sensitive fields. In others, hosted fields are placed separately into your page and your server receives a token rather than raw card data.
This approach usually gives you more control over layout and fewer visible page transitions. It also creates more integration responsibility. You must manage browser behavior, content security policy, script inventory, responsive layouts, error states, accessibility, and the compliance implications of every element surrounding the embedded payment component.
A redirect is usually the safer operational starting point for a small team. An iframe or hosted-field model makes more sense when checkout continuity, branded design, and mobile experience justify the additional testing and governance.
Pros and Cons of Hosted Payment Gateways
Hosted checkout solves a real problem: it keeps the merchant from owning the most sensitive part of card payment collection. The provider supplies the payment page, security controls, updates, and often the authentication experience. That reduces the amount of payment infrastructure your team must design and operate.
The benefit is strongest for a company with limited security engineering capacity. A retailer can focus on orders, inventory, customer support, and reconciliation instead of building encryption, card tokenization, vaulting, and network segmentation controls. Hosted checkout also provides a clearer operational boundary when incidents occur because the provider owns the payment page itself.
Where hosted checkout works well
- Reduced PCI scope: When all payment-page elements come directly from a PCI-compliant third party and the merchant doesn't store, process, or transmit account data, the architecture may fit the simpler SAQ A path. The precise outcome depends on implementation and assessor guidance, as explained in hosted versus self-hosted payment gateway guidance.
- Faster delivery: A hosted page removes much of the work involved in creating and maintaining card-entry infrastructure. This often makes it a sensible choice for an MVP, a small online store, or a business entering a new market.
- Provider-managed changes: The gateway typically manages payment-page security updates, supported authentication flows, and payment method changes. Your team still needs to test compatibility, but you're not maintaining the entire card form.
- Operational resilience: Providers commonly offer established retry, authorization, and payment-status mechanisms. That doesn't remove the need for good backend design, but it reduces the number of payment components you must build from scratch.
Where the trade-off appears
The customer may notice the redirect. A technical guide from Hyperswitch on payment integration cites a 3–7 percentage-point mobile conversion drop for redirected checkout compared with API-based flows. Treat that as a scenario to measure, not a guaranteed outcome. A trusted brand with a familiar provider page may perform well, while an abrupt transition, slow load, or confusing return path can cause abandonment.
Brand control is another limitation. You can often apply a logo, colors, and basic text, but you won't control every field, animation, validation message, or release schedule. The gateway also becomes a dependency. Outages, changed payment-method behavior, account reviews, and provider pricing can affect your checkout even when your own application is healthy.
Practical rule: Choose hosted checkout when reducing security ownership matters more than controlling every pixel. Choose a different model only when you can fund the engineering, testing, and compliance work that greater control requires.
Hosted vs Direct vs Hybrid Payment Integration
The decision isn't solely hosted versus self-hosted. Production systems usually fall on a spectrum between provider-controlled checkout and merchant-controlled payment orchestration.
A hosted integration sends customers to a provider page. A direct integration collects payment details through merchant-controlled interfaces and sends them to the processor through an API. A hybrid integration keeps the surrounding checkout on the merchant's site but uses hosted fields, tokens, SDKs, or a provider-controlled modal for sensitive elements.
| Model | PCI compliance burden | Customization | Delivery speed | Security responsibility |
|---|---|---|---|---|
| Hosted redirect | Lower in suitable architectures | Lower | Faster | Primarily provider, with merchant obligations |
| Direct | Higher | Highest | Slower | Primarily merchant |
| Hybrid | Medium and architecture-dependent | High | Medium | Shared |
Match the model to the business
For an early-stage startup validating a product, hosted redirect usually offers the clearest path. The team can test pricing, refunds, subscription activation, and customer support workflows without making payment-page security a major product stream.
An established retailer may prefer hybrid checkout when customers expect a continuous branded experience. Hosted fields can preserve more of the site's layout while keeping card inputs under provider control. The engineering team must then govern scripts, browser behavior, callbacks, and failure states carefully.
A fintech, marketplace, or high-volume SaaS platform may eventually need direct or hybrid orchestration for routing, stored payment credentials, account-level controls, complex retries, or multiple processors. That doesn't make direct integration automatically better. It makes the extra ownership potentially worthwhile.
The right question is not “Which option is most advanced?” It's “Which responsibilities can our team operate reliably over the next 2–3 years?” That time horizon matters because payment architecture creates long-lived obligations around monitoring, incident response, reconciliation, and compliance.
| Business condition | Usually suitable | Why |
|---|---|---|
| Limited engineering and compliance capacity | Hosted | Reduces implementation and card-data ownership |
| Strong brand and conversion optimization needs | Hybrid | Preserves checkout continuity with shared responsibility |
| Dedicated payments engineering team | Direct or hybrid | Supports deeper orchestration and control |
| Rapid international expansion | Hosted or hybrid | Lets the provider handle more local payment complexity |
| Complex marketplace settlement | Hybrid or direct | May require stronger control over accounts and fund flows |
Teams building broader financial products can also review this fintech app development, payments, wallets, and compliance guide before committing to an architecture.
PCI Compliance and Security Requirements
Hosted checkout reduces PCI exposure, but it doesn't mean zero compliance work. That distinction became more important in 2025, when PCI DSS v4.0.1 changed the practical conversation around payment pages, client-side scripts, and ongoing monitoring. The PCI Security Standards Council provides the governing guidance and updates that merchants and service providers should use when confirming their obligations.
The architecture determines the likely Self-Assessment Questionnaire path. A fully redirected page, where the payment form comes directly from the compliant provider and your environment never handles account data, may support SAQ A. A page that embeds payment functionality while your site controls surrounding scripts and content can require a different assessment, potentially SAQ A-EP, depending on the exact design and responsibilities.
That means the word “hosted” isn't enough. A redirect, an iframe, hosted fields, and a custom modal can each create a different scope profile.
What remains your responsibility
Your storefront can still affect the security of the payment experience. PCI DSS v4.0.1 places greater emphasis on knowing which scripts run on payment-related pages, controlling unauthorized changes, and monitoring for suspicious behavior. A third-party payment form doesn't automatically protect the page that loads it.
Use this operational checklist before launch:
- Map the flow: Document every page, script, iframe, SDK, redirect, webhook, and server-side payment call.
- Confirm data boundaries: Verify whether card data touches your browser, servers, logs, analytics tools, support systems, or databases.
- Ask for written scope guidance: Request the provider's integration-specific PCI documentation, not a generic statement that the gateway is compliant.
- Control scripts: Maintain an inventory of scripts on payment pages and review who can add or change them.
- Monitor changes: Set up detection for unexpected payment-page modifications and investigate alerts.
- Protect callbacks: Authenticate webhooks, validate signatures, make order updates idempotent, and reject replayed events.
- Test failure paths: Cover abandoned sessions, duplicate callbacks, delayed authorization, 3D Secure challenges, refunds, and browser refreshes.
A payment processor is the party that routes and handles authorization, but that term covers several operating models. This payment processor glossary entry from RecurX can help non-specialists separate the processor, gateway, acquirer, and merchant roles.
For a deeper implementation checklist, use Technioz's PCI DSS compliance checklist, then confirm the final interpretation with your acquiring bank, qualified security assessor, or compliance adviser. The safest hosted integration is the one whose scope you can explain clearly, test repeatedly, and document for an auditor.
Choosing and Migrating to a Hosted Payment Gateway
Start vendor selection with business behavior, not a feature sheet. A gateway that accepts cards but handles your refunds, subscriptions, currencies, settlement reports, and customer support poorly can create more work than it removes.
Evaluate the provider
Ask each vendor to demonstrate the full payment lifecycle, including:
- Payment methods and geography: Confirm the cards, wallets, bank methods, currencies, countries, and settlement destinations your customers need.
- Integration behavior: Check whether the gateway uses dynamic sessions, SDKs, hosted fields, webhooks, or a redirect. A hosted payment page commonly needs a generated redirect URL or session parameter rather than a fixed static endpoint, as shown in the Nexi hosted payment page documentation.
- Commercial terms: Model processing fees, currency conversion, refunds, disputes, reserves, minimums, and payout timing. Don't judge cost from the headline transaction rate alone.
- Operational tooling: Review dashboards, exports, reconciliation data, webhook retries, idempotency support, dispute workflows, and access controls.
- Reliability and support: Ask how incidents are communicated, how support escalates technical issues, and how you can verify payment status during an outage.
- Risk fit: Some industries face underwriting restrictions or additional review. If your business operates in a regulated or higher-risk category, this guide to the best gateway for high risk merchants provides a useful comparison point.
Migrate without risking revenue
Run the new gateway beside the existing flow before switching traffic. Build a payment adapter so your application talks to a stable internal interface rather than scattering provider-specific logic across checkout, orders, subscriptions, and refunds.
Test with provider sandbox cases, then add controlled production verification. Check successful payments, declined cards, expired sessions, duplicate submissions, delayed webhooks, partial refunds, full refunds, chargebacks, authentication challenges, and customer returns from the provider page.
Keep a rollback plan that your support and operations teams understand. Define which gateway owns each transaction during the transition, how reconciliation will identify the provider, and how you'll prevent a retry from creating a duplicate order.
Use API-first development for modern software principles when designing the adapter and webhook contracts. The goal is not abstract elegance. It's the ability to replace, add, or fail over a payment provider without rewriting the rest of your commerce system.
Technioz provides payment gateway integration across one-time payments, subscription billing, webhook reconciliation, refund automation, and related web, mobile, and cloud systems. Visit Technioz to discuss a payment architecture that fits your checkout goals, compliance responsibilities, and migration risk.
Get clear on your technology strategy
Our consulting and strategy guide covers discovery, stack choice, roadmapping, and choosing the right partner.
Get a custom software estimate