# Hosted vs Self-Hosted Payment Gateway: Which Is Right for Your SaaS?

> Hosted vs self-hosted SaaS payment gateway compared: PCI scope (SAQ A, A-EP, D), dev effort, conversion, and control, plus how to choose for SaaS.
- **Author**: Ayush Agarwal
- **Published**: 2026-06-08
- **Category**: Payments, Architecture, SaaS
- **URL**: https://dodopayments.com/blogs/en/hosted-vs-self-hosted-payment-gateway

---

A hosted payment gateway runs the checkout page on the provider's servers, so card data never touches your application and your PCI scope stays at SAQ A. A self-hosted payment gateway puts the checkout on your own pages, which gives you full control of the UI but raises your PCI scope to SAQ A-EP or SAQ D depending on how card data is handled. An embedded or overlay checkout sits in between: the provider's secure frame renders inside your page, so you keep most of the UX control with hosted-level PCI scope.

For most SaaS companies, the right SaaS payment gateway setup is hosted or embedded checkout, not a fully self-hosted form. The decision controls PCI compliance scope, integration speed, branding, conversion, and how much engineering work you sign up for over the lifetime of the product. This guide compares all three models and gives a practical way to choose.

## 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
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 to SAQ A, the simplest questionnaire.

Common examples of hosted flows include Stripe Checkout in redirect mode, PayPal Checkout, Square hosted checkout, and the Dodo Payments hosted checkout page created through a [checkout session](https://docs.dodopayments.com/developer-resources/checkout-session).

## What "embedded" or "overlay" checkout means

Embedded checkout is still hosted by the provider, but it is displayed inside your application instead of on a separate page. There are two common patterns:

- **Overlay (modal) checkout:** the provider's checkout opens as a layer on top of your page. The customer never leaves your URL. Dodo Payments offers this as [overlay checkout](https://docs.dodopayments.com/developer-resources/overlay-checkout).
- **Inline checkout:** the provider's secure frame is embedded directly into your page layout, while your page shows the items, totals, and plan details. Dodo Payments offers this as [inline checkout](https://docs.dodopayments.com/developer-resources/inline-checkout).

In both cases, the card fields are served from the provider inside an iframe. Your page never reads the card number, so PCI scope stays close to a hosted redirect while the experience feels native to your product.

## What "self-hosted" actually means

A self-hosted payment gateway means your application collects card data on a page you serve. In the most literal version, the card number, expiry, and CVV pass through your servers 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 questionnaire, with significant compliance overhead.

Most modern "self-hosted" implementations use **client-side tokenization** to keep raw card data out of the backend:

- Your frontend uses the gateway's JavaScript SDK or hosted fields
- The card is tokenized in the browser and sent directly to the gateway
- Your server only ever sees the token, not the raw card
- Your page still controls how the payment form is loaded, which is what drives the SAQ level

Examples include Stripe Elements and Braintree hosted fields. Whether these land in SAQ A or SAQ A-EP depends on the exact mechanism, which the PCI section below explains.

## Hosted vs embedded vs self-hosted: comparison table

| Dimension | Hosted (redirect) | Embedded / overlay | Self-hosted with tokenization | Fully self-hosted (raw card data) |
|---|---|---|---|---|
| Card data on your servers | No | No | No | Yes |
| Typical PCI scope | SAQ A | SAQ A | SAQ A or SAQ A-EP, depending on how fields load | SAQ D |
| Dev effort | Lowest: create a session, redirect | Low: session plus a front-end SDK | Medium to high: build and maintain the form | Highest: form, security controls, audits |
| Conversion | Redirect adds a step, customer leaves your domain | Customer stays on your page | Customer stays on your page | Customer stays on your page |
| UI control | Logo, colors, limited fields | Layout around the frame is yours | Full control of layout and styling | Full control |
| Mobile experience | Depends on provider page | Provider frame is responsive inside your layout | You own responsive testing | You own responsive testing |
| Maintenance | Provider handles it | Mostly provider | You handle UI and SDK upgrades | You handle everything, including security |
| Payment method coverage | Provider's full set | Provider's full set | Whatever you integrate | Whatever you integrate |

For most early-stage SaaS, hosted or overlay checkout is the right answer because it ships fastest and minimizes PCI scope. For mid-market and consumer SaaS where checkout conversion is meaningful, inline or tokenized checkout is usually worth the additional engineering. Fully self-hosted checkout with raw card data is rarely justified for SaaS.

## PCI DSS scope: SAQ A vs SAQ A-EP vs SAQ D

The PCI Data Security Standard (PCI DSS) is maintained by the PCI Security Standards Council. Merchants that are not large enough to need an on-site assessment validate compliance with a Self-Assessment Questionnaire (SAQ). Which SAQ you file is determined mainly by how your checkout touches card data.

| SAQ | When it applies to e-commerce | What it means in practice |
|---|---|---|
| SAQ A | All cardholder data functions are fully outsourced to a PCI DSS compliant provider. The payment page, or every element of it, is delivered directly from the provider, for example a redirect or an iframe. You do not store, process, or transmit card data. | The shortest questionnaire. You still secure your own site and confirm your provider's compliance. |
| SAQ A-EP | Payment processing is outsourced, but your website controls how card data reaches the provider, for example a direct post form or JavaScript that builds the payment form on your page. Your site never receives card data. | Considerably more requirements than SAQ A, because a compromise of your web server could compromise payments. |
| SAQ D | Everything else, including any setup where card data is stored, processed, or transmitted on your systems. | The full set of PCI DSS requirements, which usually means dedicated security work and often outside assessors. |

A few standard points are worth knowing:

- **Merchant levels are separate from SAQs.** Card networks classify merchants by transaction volume. Visa Level 1, for example, covers merchants processing over 6 million Visa transactions a year, and those merchants typically need an annual Report on Compliance from a Qualified Security Assessor instead of a self-assessment.
- **Iframes vs scripts matter.** Card fields delivered in an iframe from the provider generally keep you in SAQ A. JavaScript that builds the form in your own page, or a form that posts directly from your page to the provider, generally moves you to SAQ A-EP.
- **Your provider's own certification matters.** SAQ A only works if the provider you outsource to is itself PCI DSS compliant. Dodo Payments is PCI DSS Level 1 certified.
- **Confirm with your acquirer.** Your acquiring bank or payment provider decides which validation it accepts from you, so check their documentation for each integration mode rather than assuming.

For nearly all SaaS use cases, the goal is to stay in SAQ A. Choosing SAQ D voluntarily is a significant ongoing cost that almost no SaaS founder should sign up for. For the broader security picture, see [payment security best practices](https://dodopayments.com/blogs/payment-security-best-practices).

> 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

## 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
- You want the smallest possible PCI scope
- Your checkout volume is low enough that a redirect step is an acceptable trade-off
- Your customers are used to redirect-based checkout, which is common in B2B SaaS

The trade-off you accept: some branding compromise, some friction from the redirect, and limited control over UX details.

## When to choose embedded or overlay checkout

Pick overlay or inline checkout when:

- You want the customer to stay on your pricing or upgrade page
- You want SAQ A scope without building your own card form
- You want the provider's full payment method coverage without integrating each method
- You need checkout events in your front end, for example to update the UI when checkout opens, closes, or errors

This is the default recommendation for most product-led SaaS. It captures most of the conversion benefit of a custom checkout for a fraction of the engineering cost.

## When to choose self-hosted (with tokenization)

Pick a self-hosted, tokenized checkout when:

- Checkout conversion materially affects revenue and you want to test every element
- Brand consistency through the entire flow is important for premium positioning
- You want to run A/B tests on checkout layout continuously
- You are combining multiple payment methods in one unified custom UI
- You have engineering capacity to maintain a custom checkout long term

The trade-off: more engineering work upfront, potentially heavier PCI scope, and ongoing maintenance as payment methods and SDKs evolve.

## How to choose a payment gateway model for SaaS

Use these questions in order. The first one that gets a clear answer usually decides it.

1. **Do you want to own tax, invoicing, and chargebacks?** If not, start with a Merchant of Record, then pick the checkout mode. This removes the biggest operational burden before UX is even considered.
2. **How much engineering time can you spare every quarter?** If the answer is close to zero, choose hosted or overlay. Self-hosted checkout is never a one-time project.
3. **Where do customers pay?** If upgrades happen inside your app, overlay or inline checkout keeps them in context. If customers pay from a marketing site or an emailed link, a hosted page is fine.
4. **Who are your buyers?** B2B buyers expect invoices, tax IDs, and sometimes bank transfers. Consumer buyers expect wallets and a fast mobile flow.
5. **Which markets do you sell into?** Selling globally means local payment methods, local currencies, and 3D Secure where regulation requires it. A provider-hosted checkout usually covers these faster than a custom form. See [3D Secure authentication](https://dodopayments.com/blogs/3d-secure-3ds-payment-authentication) for how SCA affects checkout design.
6. **What will you measure?** If you cannot measure checkout conversion today, you will not benefit from the extra control of a self-hosted form yet.

A simple rule of thumb: start with hosted or overlay checkout, move to inline when checkout conversion becomes a board-level metric, and only consider a fully custom form when you have a specific requirement a provider frame cannot meet.

## When to avoid the choice: use a merchant of record

There is a third option that sidesteps most of this. 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 or overlay checkout:** fastest integration, the customer is handled by the MoR's checkout on a hosted page or in a modal
- **MoR with inline checkout:** more control, the customer stays in your UI, and the MoR still owns the legal seller role

In both cases, the MoR is the legal seller, collects and remits VAT, GST, and sales tax, and handles chargebacks and compliance. Dodo Payments covers 220+ countries and territories, with tax calculation, filing, and reporting in 190+ countries. The hosted vs self-hosted question becomes a UX choice, not a compliance choice. [Merchant of record for SaaS](https://dodopayments.com/blogs/merchant-of-record-for-saas) goes deeper on that model.

Here is what an overlay integration looks like with Dodo Payments. The server creates a checkout session, and the front end opens it in an overlay:

```typescript
// Server: create a checkout session
import DodoPayments from 'dodopayments';

const client = new DodoPayments({
  bearerToken: process.env.DODO_PAYMENTS_API_KEY,
  environment: 'test_mode',
});

const session = await client.checkoutSessions.create({
  product_cart: [{ product_id: 'pdt_abc', quantity: 1 }],
  customer: { email: 'buyer@acme.com' },
  return_url: process.env.CHECKOUT_RETURN_URL, // your success page
});
// Send session.checkout_url to the browser
```

```typescript
// Browser: open the session as an overlay
import { DodoPayments } from 'dodopayments-checkout';

DodoPayments.Initialize({
  mode: 'test',
  displayType: 'overlay', // use 'inline' with an elementId to embed in the page
  onEvent: (event) => {
    if (event.event_type === 'checkout.error') {
      console.error(event.data?.message);
    }
  },
});

// checkoutUrl is the session.checkout_url value returned by your server
DodoPayments.Checkout.open({ checkoutUrl });
```

Checkout session URLs are single-use and expire after 24 hours by default, so create one per purchase attempt rather than caching them. Confirm payment outcomes on your server with [webhooks](https://docs.dodopayments.com/developer-resources/webhooks) such as `payment.succeeded` and `payment.failed`, not with the front-end event alone.

## Quick picks by SaaS type

- **Early-stage SaaS shipping in a week:** hosted or overlay checkout. Get to revenue first and iterate later.
- **Consumer SaaS optimizing for conversion:** inline checkout or a tokenized form, tested continuously.
- **B2B SaaS with annual contracts:** hosted or overlay checkout for self-serve, with "Purchase as a business" enabled so buyers can enter a tax ID, plus invoiced billing for larger contracts.
- **Global product-led SaaS:** a merchant of record with whichever checkout mode fits your conversion priorities.

## What hosted gateways often hide

A few things are not always obvious about hosted gateway products.

### 1. Redirect-based conversion loss

Sending customers to a third-party domain adds a step and a moment of doubt, and some customers drop off. The impact varies widely by audience and brand. For low-price, high-volume SaaS even a small drop matters; for B2B SaaS with engaged buyers the impact is usually small. Overlay and inline checkout remove the redirect.

### 2. Limited customization

Hosted checkout pages have configurable colors, logos, and a few field options, but you cannot rearrange the layout or add arbitrary custom fields. If your signup needs unusual 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 coverage in long-tail markets varies by provider. Dodo Payments checkout supports 21 languages and 40+ payment methods.

## What self-hosted often costs

Self-hosted checkout has hidden ongoing costs:

- The initial engineering build, which grows with every payment method you add
- Ongoing maintenance as gateway SDKs release new versions
- Mobile testing across browsers and devices
- A/B testing infrastructure for conversion optimization
- Compliance reviews when adding payment methods or changing how the form loads
- Handling address verification and fraud signals yourself, such as an [AVS mismatch](https://dodopayments.com/blogs/avs-mismatch) on card payments

A finance forecast that treats self-hosted checkout as a one-time integration cost is wrong. Plan for recurring engineering time to maintain it.

## Both routes still require verification

The hosted versus self-hosted decision changes where card data lives and how much PCI scope you carry. It does not change whether you get verified.

Either way, a regulated provider must identify your legal entity, map ownership to natural persons, and screen them before settling funds to you. What does change with the account model is scope: under a direct merchant account you are onboarded by an acquirer with card network registration, while under a merchant of record the MoR holds that relationship and verifies you as the party it settles to.

Our guide to [KYB verification](https://dodopayments.com/blogs/kyb-verification) covers what each route asks for, and [merchant of record vs PSP](https://dodopayments.com/blogs/merchant-of-record-vs-psp) covers the structural difference.

## FAQ

### What is the best payment gateway setup for SaaS?

For most SaaS companies, a hosted or overlay checkout is the best starting point because it ships quickly and keeps PCI scope at SAQ A. Move to inline or tokenized checkout once checkout conversion becomes a key metric.

### Is a hosted payment gateway safer than self-hosted?

Hosted checkout is the simplest path to SAQ A because card data never reaches your pages or servers. Self-hosted checkout with proper tokenization can also be PCI compliant, but any setup that puts raw card data on your servers triggers SAQ D.

### What is the difference between SAQ A and SAQ A-EP?

SAQ A applies when the entire payment page or every payment field is delivered by your PCI compliant provider, for example through a redirect or iframe. SAQ A-EP applies when your own website controls how card data reaches the provider, such as a direct post form or a script-built payment form.

### Does hosted checkout reduce conversion?

Redirect-based hosted checkouts can lose some customers because of the extra step and the domain change. Overlay and inline checkouts that keep the customer on your page avoid most of that loss while keeping hosted-level PCI scope.

### How does a merchant of record fit into hosted vs self-hosted?

An MoR can offer hosted, overlay, and inline checkout modes. You still choose the checkout experience, but the MoR acts as the legal seller and absorbs tax, compliance, and chargeback handling, so the choice becomes a UX decision rather than a compliance one.

## Conclusion

The hosted vs self-hosted decision is mostly about engineering bandwidth and conversion ambition. Hosted checkout ships fast and stays PCI-light, embedded checkout adds control without adding scope, and self-hosted checkout lets you optimize everything at the cost of ongoing work. All three are viable for SaaS, but only one of them should be your starting point, and for most teams it is hosted or overlay.

If you want any of these models with global tax and compliance handled by your provider, [Dodo Payments](https://dodopayments.com) supports hosted, overlay, and inline checkout on top of Merchant of Record coverage in 220+ countries and territories, with no monthly or setup fees. See [pricing](https://dodopayments.com/pricing).
---
- [More Payments articles](https://dodopayments.com/blogs/category/payments)
- [All articles](https://dodopayments.com/blogs)