Hosted Page vs iframe vs API: What Each Does to Your PCI Scope

There are three ways to take money on a website: redirect the customer to the provider's page, embed the provider's iframe inside your page, or build your own form that sends the data to the provider. The difference is not cosmetic - it decides how much of the card data security standard applies to you, and who is responsible when something breaks.

The three approaches, side by side

Why does this change which PCI requirements apply to you?

The assessment firms that guide businesses through PCI DSS describe the distinction this way: when the site fully redirects the customer to a validated third party, or uses an iframe that third party supplies, the flow of cardholder data is controlled by that provider - which places the business on the short self-assessment questionnaire. When the payment form is implemented and managed by the merchant instead - a Direct Post script, for example - a far broader questionnaire applies.

The gap those firms cite is a couple of dozen requirements against roughly two hundred. That is why this is not a designer's decision:

• Your own form means every script running on your page is part of the payment environment.
• That includes analytics tools, chat widgets, pixels and plugins - each one a component to manage.
• And it means an update to a plugin unrelated to payments still touches the payment flow.

The binding definitions live with the standards council, and what actually applies to you is settled with your acquirer and your assessor - not from an article. What you can take from this: absent a strong reason, the redirect or the iframe is the correct default.

What actually drives abandonment?

The assumption that customers abandon because of a domain change is far less true than people think, especially when the provider's page is branded. What does lose transactions:

• The payment method the customer wants is missing. No Bit or digital wallet is immediate abandonment.
• No instalments. Israeli consumers look to split payments; a page without that loses the large transactions.
• Unnecessary fields. Every field not required to charge is a reason to leave.
• A slow mobile page, or an iframe whose height forces scrolling inside scrolling.
• A Hebrew error that says nothing. "The transaction failed", with no next action.

So the right order is to check payment methods and instalments first, and only then discuss the embedding type. The full breakdown is in why Israeli checkouts get abandoned.

What to check before choosing an approach

1. Whether your provider offers all three, or only some.
2. Whether the iframe is mobile-fit, and what happens when the keyboard opens.
3. Whether the provider's page can be branded, and how far.
4. What happens when a transaction fails - where the customer lands and what they read.
5. Who maintains the embed after go-live, and what happens on a store version upgrade.
6. What a refund looks like - from inside the system, or a support request.

Question five is what decides it in a business with no in-house developer. A plugin broken by a platform upgrade is the most common reason a store stops collecting, and it is usually discovered by a customer rather than by monitoring.

Who owns what, after go-live

This is the question nobody asks during implementation and everybody asks at the first incident. Write the split down once:

• The page containing the payment - yours, always. Even when the fields are the provider's.
• The card fields and their storage - the provider's, in the first two approaches.
• The success and failure message to the customer - yours. The provider returns a result; you write what it says.
• Updating the order in your system - yours, and always from the server notification rather than the browser's return.
• The plugin connecting store to provider - depends who built it. The provider's official plugin is theirs; a third-party one is yours.
• The month-end reconciliation report - yours.

The last line is the forgotten one. Even when everything sits with the provider, matching what was charged against what reached the bank is your work, and no embedding method changes that.

What goes wrong in each approach

• Redirect: the customer lands on the thank-you page before the provider's notification arrives, and the order looks unpaid. Fix: rely on the server-to-server update, not on the browser's return.
• iframe: a fixed height producing double scrolling on mobile, or third-party blocking in the browser preventing it from loading.
• Own form: an external script that changes without notice and touches the payment page - precisely why your scope is larger.
• All three: no report showing how many transactions opened against how many completed, so nobody knows there is a problem.

When you do build your own form

There are situations where it is the right call, and they are narrow:

• A subscription or renewal inside a product where the user is already logged in, and leaving for an external page breaks the flow.
• A multi-step process where payment is one step among several and you cannot exit midway.
• Charging without the customer present, such as an automatic renewal on an existing token - which is not a form at all but a server call.
• A marketplace that has to split an amount between several sellers.

In each of those, the decision belongs with whoever will maintain it for two years, not with the start of a project. And in every case, storing the card itself still stays with the provider as a token, as explained in what a payment token is.

Sources

• PCI Security Standards Council - official document library
• Foregenix - the difference between SAQ A and SAQ A-EP, analysis by an assessment firm
• PayPlus - integrations and iFrame or Redirect embedding