# Hosted vs Self-Hosted Payment Gateway: Which Is Right for Your SaaS? > Hosted vs self-hosted payment gateway compared. PCI scope, control, integration speed, and which model fits SMB SaaS, enterprise, and global product-led companies. - **Author**: Ayush Agarwal - **Published**: 2026-06-08 - **Category**: Payments, Architecture, SaaS - **URL**: https://dodopayments.com/blogs/hosted-vs-self-hosted-payment-gateway --- A hosted payment gateway is one where the provider runs the entire checkout infrastructure on their servers, and you redirect customers to their domain to enter payment details. A self-hosted (or "on-merchant") payment gateway runs on your own infrastructure, with you owning the checkout flow and handling card data inside your application. The distinction sounds technical but it controls PCI compliance scope, integration speed, branding flexibility, and how much engineering work you sign up for over the lifetime of the product. This guide explains both models and helps SaaS founders pick the right one. ## What "hosted" actually means When a payment gateway is hosted, the provider hosts the page that collects card data. A typical flow: 1. Customer clicks "Pay" in your SaaS 2. Your backend creates a checkout session with the gateway 3. The customer is redirected to a URL on the gateway's domain (or shown an iframe served from the gateway) 4. Customer enters card details on the gateway's hosted page 5. Gateway charges the card and returns the customer to your site with a success or failure status The card data never touches your servers. From a PCI DSS perspective, this dramatically reduces your compliance scope (typically SAQ A, the simplest level). Examples of hosted gateway flows: Stripe Checkout (redirect mode), PayPal Checkout, Square hosted checkout, [overlay checkout](https://docs.dodopayments.com/developer-resources/overlay-checkout) products that render the form in an iframe. ## What "self-hosted" actually means A self-hosted payment gateway means your application collects card data on a page you serve. The card number, expiry, and CVV pass through your servers (or at least your application's frontend) on the way to the gateway's API. A typical flow: 1. Customer enters card details on your checkout page 2. Your frontend or backend sends the card data to the gateway's API 3. Gateway charges the card and returns the result 4. Your application shows success or failure This gives you full control of the UI and the customer experience. The cost is dramatically higher PCI scope. If raw card data ever touches your servers, you fall into SAQ D (the most demanding level) or higher, with significant compliance overhead. Most modern "self-hosted" implementations actually use **client-side tokenization** to keep raw card data out of the backend: - Your frontend uses the gateway's JavaScript SDK - The SDK tokenizes the card client-side and sends it directly to the gateway - Your server only ever sees the token, not the raw card - This keeps PCI scope manageable (SAQ A-EP) while letting you control the UI Examples: Stripe Elements, [inline checkout](https://docs.dodopayments.com/developer-resources/inline-checkout) integrations, Braintree's hosted fields. ## Comparison at a glance | Dimension | Hosted | Self-hosted (with tokenization) | |---|---|---| | Card data on your servers | No | No (with SDK tokenization) | | PCI scope | SAQ A (lightest) | SAQ A-EP (light, but more than SAQ A) | | UI control | Limited (provider's design) | Full control | | Integration time | Hours to days | Days to weeks | | Conversion impact | Slight friction from redirect | Best conversion (no redirect) | | Mobile experience | Sometimes clunky on redirect | Native, seamless | | Branding | Co-branded with provider | Fully yours | | Maintenance burden | Provider handles it | You handle UI changes | For most early-stage SaaS, hosted is the right answer because it ships fastest and minimizes PCI scope. For mid-market and enterprise SaaS where checkout conversion is meaningful, self-hosted with tokenization is usually worth the additional engineering. ## When to choose hosted Pick a hosted payment gateway when: - You are early-stage and need to ship in days, not weeks - Your team has minimal payments expertise - PCI compliance is daunting and you want to minimize scope - Your checkout volume is low enough that a few percent conversion loss is acceptable - Your customers are accustomed to redirect-based checkout (B2B SaaS, marketplaces) The trade-off you accept: some branding compromise, some friction from the redirect, and limited control over UX details. ## When to choose self-hosted (with tokenization) Pick self-hosted when: - Checkout conversion materially affects revenue (consumer SaaS, high-velocity SMB) - Brand consistency through the entire flow is important (premium positioning) - You want to A/B test checkout elements continuously - You are integrating multiple payment methods that benefit from a unified UI - You have engineering capacity to maintain a custom checkout The trade-off: more engineering work upfront, slightly heavier PCI scope, ongoing maintenance as payment methods evolve. ## When to avoid both: use a merchant of record There is a third option that sidesteps the choice. A [merchant of record](https://dodopayments.com/blogs/what-is-a-merchant-of-record) (MoR) like Dodo Payments handles the entire payment, tax, and compliance stack for you. You can still choose between: - **MoR with hosted checkout** ([overlay checkout](https://docs.dodopayments.com/developer-resources/overlay-checkout)): fastest integration, customer is briefly handled by the MoR's checkout - **MoR with inline checkout** ([inline checkout](https://docs.dodopayments.com/developer-resources/inline-checkout)): more control, customer stays in your UI, MoR still owns the legal seller role In both cases, the MoR absorbs sales tax registration, VAT filings, chargeback liability, and global compliance across 190+ tax jurisdictions and 220+ countries and regions. The hosted vs self-hosted question becomes a UX choice, not a compliance choice. > The hosted vs self-hosted decision used to be about PCI scope. With modern tokenization SDKs, both are PCI-friendly. The real question is now about conversion, brand consistency, and whether you want to own the checkout experience or hand it off. > > \- Ayush Agarwal, Co-founder & CPTO at Dodo Payments ## PCI scope in detail The PCI DSS standard defines self-assessment questionnaires (SAQs) by integration type: | SAQ Level | When it applies | Audit burden | |---|---|---| | SAQ A | Card data fully outsourced to a redirect or iframe (hosted) | Minimal | | SAQ A-EP | Tokenization on your domain via gateway SDK | Light | | SAQ D | Card data touches your servers | Heavy, often requires QSA | | Level 1 audit | Over 6M transactions per year | Annual external audit | For nearly all SaaS use cases, the goal is to stay in SAQ A or SAQ A-EP. Achieving SAQ D or higher voluntarily is a significant ongoing cost that almost no SaaS founder should sign up for. A hosted payment gateway puts you firmly in SAQ A. A tokenized self-hosted integration puts you in SAQ A-EP. Both are manageable for small teams. ## Real-world examples ### Early-stage SaaS shipping in 1 week Use Stripe Checkout (hosted) or Dodo Payments overlay checkout. Skip custom UI work. Get to revenue, learn what your customers care about, iterate later. ### Consumer SaaS optimizing for conversion Use Stripe Elements or Dodo Payments inline checkout. Keep customers in your branded UI through the entire payment flow. A/B test button colors, layout, and copy continuously. ### B2B SaaS with annual contracts Use a hosted checkout for self-serve customers. Use invoiced billing (with optional ACH/wire) for annual enterprise contracts. The mix is standard for B2B SaaS. ### Global product-led SaaS Use a merchant of record with whichever checkout mode (overlay or inline) fits your conversion priorities. The MoR handles tax, compliance, and local payment methods automatically. ## What hosted gateways often hide A few things are not always obvious about hosted gateway products: ### 1. Redirect-based conversion loss Some studies show 5% to 15% drop-off when customers are redirected to a third-party domain for checkout. This varies wildly by audience and brand. For low-AOV high-volume SaaS, even 5% matters. For B2B SaaS with engaged buyers, the impact is usually negligible. ### 2. Limited customization Hosted checkout pages have configurable colors, logos, and a few field options, but you cannot rearrange the layout or add custom fields. If your subscription requires unusual signup data, you may end up collecting it on a pre-checkout page (which fragments the flow). ### 3. Localization variation Hosted checkouts are usually well-localized for major languages and payment methods, but long-tail markets may have gaps. Self-hosted lets you compose any payment method coverage you want. ## What self-hosted often costs Self-hosted checkout has hidden ongoing costs: - Initial engineering build (1 to 4 engineer-weeks depending on scope) - Ongoing maintenance as gateway SDKs version - Mobile testing across browsers and devices - A/B testing infrastructure for conversion optimization - Compliance reviews when adding payment methods A finance forecast that treats self-hosted as a one-time integration cost is wrong. Plan for ongoing 5% to 10% of engineering time to maintain it. ## FAQ ### Is hosted payment gateway safer than self-hosted? Both can be PCI-compliant. Hosted is the simplest path to SAQ A. Self-hosted with proper tokenization is SAQ A-EP, which is also manageable. Avoid implementations that put raw card data on your servers (that triggers SAQ D, which is heavy). ### Does hosted checkout reduce conversion? Sometimes. Redirect-based hosted checkouts can lose 5% to 15% of conversions due to the extra step. Iframe or overlay-based hosted checkouts that keep the customer on your domain typically have minimal conversion impact. ### What is the fastest hosted gateway to integrate? Modern hosted checkout products integrate in hours. Stripe Checkout, PayPal, and Dodo Payments overlay checkout are all sub-day integrations for a simple product. Custom checkout flows take days to weeks. ### Should I build a fully custom self-hosted payment page? Only if you have a specific reason (very high volume, unique UX, branding requirements that hosted cannot meet). For most SaaS, hosted or tokenized inline checkout is the better tradeoff. ### How does a merchant of record fit into hosted vs self-hosted? An MoR can offer both modes. You still choose between hosted and inline, but the MoR absorbs tax, compliance, and chargeback handling across all your customers. The choice between hosted and inline becomes purely a UX choice, not a compliance one. ## Conclusion The hosted vs self-hosted decision is mostly about engineering bandwidth and conversion ambition. Hosted ships fast and stays PCI-light. Self-hosted ships slower and lets you optimize the whole flow. Both are viable for SaaS. If you want either model with global tax and compliance handled by your provider, [Dodo Payments](https://dodopayments.com) supports both hosted overlay and inline checkout, on top of MoR coverage in 220+ countries and regions. See [pricing](https://dodopayments.com/pricing). --- - [More Payments articles](https://dodopayments.com/blogs/category/payments) - [All articles](https://dodopayments.com/blogs)