Hosted payment pages and PCI compliance: reducing your scope

PCI DSS compliance is significantly simpler when your systems never touch card data. Hosted payment pages, where your payment processor handles the card entry form on their own infrastructure, are the primary tool ecommerce merchants use to reduce PCI scope. The difference can be dramatic: SAQ-D requires compliance with 329 requirements; SAQ-A requires 22.

But scope reduction is not automatic. The type of hosted payment integration you use determines how much scope reduction you actually get, and PCI DSS 4.0 introduced new considerations that affect the scope analysis.

The three types of hosted payment integration

Payment integrations fall into three broad categories with different PCI implications:

• Full redirect. The customer clicks a payment button on your site and is sent entirely to the payment processor's domain. They enter card details on the processor's page. Your servers are never involved in handling card data. After payment, the customer is redirected back to your order confirmation page. Examples: PayPal Standard, Stripe Checkout (payment link mode), some Klarna configurations.
• Embedded iframe. Your checkout page hosts an iframe that loads from the payment processor's domain. The card entry form is inside the iframe. Your page's JavaScript cannot read the iframe's contents due to browser same-origin policy. Card data is submitted directly from the iframe to the processor. Examples: Stripe Elements, Braintree Hosted Fields, Adyen Drop-in, Worldpay Embedded.
• JavaScript tokenization. You load a JavaScript SDK from your payment processor that runs on your page. When the customer submits the card form, the SDK tokenizes the card number in the browser and your server only receives a token. Card data passes through the processor's SDK but not your server. Examples: Stripe.js with custom forms, Braintree SDK.

How integration type maps to SAQ type

The SAQ type you qualify for depends primarily on your integration type:

• Full redirect: SAQ-A. If you redirect entirely to a hosted payment page and your site has no scripts running during the payment step (because the customer is not on your domain), you may qualify for SAQ-A. This has 22 requirements and no pen testing obligation for most merchants.
• Embedded iframe with scripts on parent page: SAQ-A with 4.0 requirements. Under PCI DSS 4.0, if your checkout page has a payment iframe plus other JavaScript, you qualify for a modified SAQ-A that includes script management requirements (6.4.3 and 11.6.1). Our guide on PCI DSS 4.0 SAQ-A changes covers the updated eligibility criteria. This is still substantially less work than SAQ-D but adds monitoring obligations.
• JavaScript tokenization: SAQ-A-EP. When a payment SDK runs JavaScript on your page that directly handles or processes card data (even transiently before tokenization), you move to SAQ-A-EP with 193 requirements. This includes web application vulnerability scanning and penetration testing obligations.
• Self-hosted forms or any server-side card handling: SAQ-D. Full 329 requirements. Extensive testing, auditing and infrastructure requirements.

Stripe: Checkout vs Elements vs Payment Links

Stripe offers multiple integration options with different PCI implications:

• Stripe Payment Links. The simplest integration: you create a payment link in the Stripe dashboard and share it with customers. The customer goes to a Stripe-hosted URL. You have no checkout page at all. This is the maximum scope reduction: you qualify for SAQ-A and your obligations are minimal.
• Stripe Checkout (redirect mode). You initiate a Stripe Checkout session from your server and redirect the customer to a Stripe-hosted checkout page. The customer enters card details on Stripe's domain. After payment, they return to your site. This is a full redirect and qualifies for SAQ-A.
• Stripe Elements. You embed Stripe-provided iframe components directly in your checkout page. The card number, expiry and CVV fields are each an iframe hosted by Stripe. Your page's JavaScript does not have access to card data. Under PCI DSS 4.0, you qualify for SAQ-A but with script management requirements for other scripts on your checkout page.
• Custom Stripe.js forms. You use Stripe.js but build the form elements yourself rather than using Elements iframes. Stripe's SDK tokenizes card data in the browser. This moves you to SAQ-A-EP because the card data handling occurs in JavaScript on your page.

Stripe explicitly documents SAQ eligibility for each integration type on their PCI compliance page. If your integration type does not match one of the clearly documented options, contact Stripe's compliance team for clarification.

Braintree: Drop-in vs Hosted Fields

Braintree (owned by PayPal) similarly offers multiple integration options:

• Braintree Drop-in UI. Braintree's pre-built payment form that you embed in your page. The form is contained within iframes hosted by Braintree. Card data does not touch your page. This is an iframe integration and under PCI DSS 4.0 qualifies for SAQ-A with script management requirements.
• Braintree Hosted Fields. Individual iframe fields (card number, CVV, expiry) that you embed and style within your own form. Similar to Stripe Elements in terms of PCI scope: each field is an iframe from Braintree's domain. SAQ-A with script management requirements.
• Braintree JavaScript SDK (direct integration). Braintree's SDK handles tokenization on your page. SAQ-A-EP applies.
• PayPal buttons on your page. When customers click a PayPal button, they are redirected to PayPal's domain to complete payment and returned to your site after. Full redirect: SAQ-A, minimal obligations.

Adyen Drop-in

Adyen's Drop-in is an embedded payment form that loads within an iframe on your checkout page. Card data is entered directly into Adyen's hosted fields and transmitted to Adyen's servers. Your page hosts the Drop-in container but does not have access to card data within it.

Under PCI DSS 4.0, Adyen Drop-in qualifies for SAQ-A with script management requirements (given that your checkout page typically has other JavaScript present alongside the Drop-in). Adyen provides its own SAQ eligibility documentation and offers PCI compliance support to merchants.

Residual PCI obligations even with hosted pages

Choosing a hosted payment integration does not eliminate all PCI obligations. Even SAQ-A merchants have requirements to fulfill:

• Quarterly vulnerability scans. Some SAQ-A merchants have scanning requirements depending on their network configuration. Confirm with your acquirer whether this applies to you.
• Script management (PCI DSS 4.0). If your checkout page has any scripts alongside a payment iframe, requirements 6.4.3 and 11.6.1 apply. You need a script inventory, authorization process and tamper detection.
• Third-party compliance verification. You must confirm that your payment processor is PCI DSS compliant and has a current Attestation of Compliance. This is a new explicit requirement in SAQ-A v4.0.
• Physical and logical security. Even merchants with minimal digital PCI scope have basic physical security requirements, such as securing devices that handle payment confirmations and maintaining password controls on systems connected to your order management.
• Annual self-assessment. Completing and submitting the SAQ annually is still required, along with your Attestation of Compliance.

The iframe security model

The security benefit of iframe-based payment forms rests on the browser's same-origin policy. Scripts on your page (origin: yourstore.com) cannot read the content of an iframe from a different origin (origin: js.stripe.com). This isolation prevents your JavaScript from accessing card numbers even if your scripts are compromised.

However, the isolation is not complete:

• Scripts on your page can overlay the iframe with a fake form (clickjacking variant). A user thinks they are typing into the payment form but they are actually typing into a malicious overlay that captures keystrokes.
• Scripts can monitor keyboard events on the parent page. Depending on how input focus moves between the parent page and the iframe, some keystrokes may be capturable by parent page scripts.
• Scripts can modify the iframe's src attribute to point to a malicious domain if CSP does not prevent it. Our guide on payment page security covers these attack vectors in detail.
• Scripts can detect which iframes are present and at what positions, potentially enabling social engineering or UI manipulation attacks.

This is why PCI DSS 4.0 added script management requirements to SAQ-A for iframe-based integrations. The isolation is meaningful but not absolute.

Redirect vs embedded: conversion impact data

The main argument against using a full redirect (which provides the best PCI scope reduction) is conversion rate impact. Customers being redirected away from your store to complete payment see higher abandonment rates.

Published data on this is mixed and context-dependent:

• Stripe's own research suggests that Stripe Checkout (redirect) converts within 5-10% of Stripe Elements (embedded) when the hosted checkout is well-designed and branded.
• Baymard Institute research shows that forced account creation and unexpected redirects are major abandonment causes, but trust in recognized payment brands (Stripe, PayPal) partially offsets redirect friction.
• B2B ecommerce typically sees less conversion impact from redirects than B2C, because B2B customers are less price-sensitive and more accustomed to varied checkout experiences.
• Mobile checkout abandonment rates are higher in all scenarios; redirect-based payments can perform comparably to embedded on mobile if the hosted page is mobile-optimized.

The conversion tradeoff is real but often overstated. For mid-market stores spending $5,000 to $25,000 annually on PCI compliance, a 2-3% conversion improvement from an embedded integration rarely justifies the increased compliance burden. Run the numbers for your specific revenue volume.

PCI DSS 4.0 specific considerations for hosted pages

Beyond script management, PCI DSS 4.0 introduced several considerations specific to hosted payment pages:

• Explicitly confirm third-party compliance. New SAQ-A language requires merchants to "confirm that their TPSP is PCI DSS compliant." Request your payment processor's current AOC (Attestation of Compliance) and keep it on file.
• Understand what your processor's compliance covers. A processor's PCI DSS compliance certificate covers their systems, not yours. It does not transfer compliance to your store. Your obligations under SAQ-A remain yours to fulfill.
• Review your integration periodically. Integration options evolve. What qualifies as SAQ-A today may change if you or your processor updates the integration. Review your SAQ eligibility annually or when you make changes to your checkout.
• Document your integration type. Keep written documentation of which integration type you use (redirect, iframe, etc.) and why it qualifies you for your chosen SAQ. This documentation supports your annual self-assessment.

Choosing the right integration for your store

The decision framework:

• If minimizing PCI compliance burden is the priority: use a full redirect. Accept the modest conversion tradeoff. Stripe Checkout, PayPal or Adyen Hosted Payment Page are solid options.
• If maximizing checkout conversion is the priority: use an embedded iframe (Stripe Elements, Braintree Hosted Fields, Adyen Drop-in). Accept the script management obligations under PCI DSS 4.0.
• If you have custom checkout UX requirements: evaluate whether those requirements actually require JavaScript tokenization (SAQ-A-EP) or whether they can be met with iframe components.
• If you are on Shopify or BigCommerce: use the platform's native hosted checkout unless you have a compelling reason not to. Platform-managed checkout reduces your compliance surface significantly.

Frequently asked questions

What is a hosted payment page?

A hosted payment page is a payment form hosted entirely on your payment processor's domain (like Stripe Checkout or PayPal). The customer leaves your site to enter card details, so your servers never touch card data. This reduces PCI scope to SAQ-A with 22 requirements.

Does using a hosted payment page eliminate PCI DSS obligations?

No. Even SAQ-A merchants must complete annual self-assessment, verify their payment processor's PCI compliance and under PCI DSS 4.0 may need script management controls if iframes are used on checkout pages.

What is the conversion rate impact of redirect vs embedded payment forms?

Published data varies, but Stripe's research suggests redirect checkout converts within 5 to 10% of embedded forms when well-designed. The compliance cost savings from reduced PCI scope often outweigh the modest conversion difference.

Which SAQ type does Stripe Elements require?

Stripe Elements uses iframes on your checkout page. Under PCI DSS 4.0, this qualifies for SAQ-A with script management requirements (6.4.3 and 11.6.1). Custom Stripe.js forms without Elements require SAQ-A-EP with 193 requirements.