Choosing between an embedded checkout and a hosted checkout seems, at first glance, like an interface decision. In one option, customers remain within the merchant's visual experience. In the other, some or all of the payment step is delivered by a specialist provider.
In practice, it is an architectural decision.
It changes who delivers the elements that collect payment data, which systems sit on the critical path, how much control the merchant has over the experience, how the integration evolves, the security surface, and how the compliance scope may change.
There is no universally better format. There is a format better suited to each operation's desired control, risk, technical capabilities, and product strategy.
What is an embedded checkout?
Embedded checkout, often called “transparent checkout” in Brazil, is a market term for an experience in which consumers complete their purchase without noticing a significant departure from the merchant's environment.
It can be implemented in several ways.
The merchant can build the page and integrate provider components. It can use hosted fields or iframes to collect sensitive data. It can tokenize the credential in the browser and send only the token to the backend. It can also use payment APIs while keeping the entire visual experience under its own brand.
That is why “transparent” describes the user experience more than a single technical design.
What is a hosted checkout?
A hosted checkout is a payment page delivered by a PSP or another specialist provider.
The merchant typically creates a session or intent, redirects the consumer to the provider's environment, and receives the result afterward through a browser return and server events.
The hosted page can handle card collection, local methods, authentication, validation, and some presentation logic.
The main benefit is outsourcing a substantial part of the payment surface.
Does a hosted checkout mean leaving the brand behind entirely?
Not necessarily.
Many providers allow customization of the logo, colors, language, and basic elements of the experience.
Even so, customization and full control are different things.
With a hosted page, the merchant accepts limits imposed by the external component. This can be positive because it reduces maintenance, but it can also limit highly specific UX experiments.
What are hosted fields?
Hosted fields are payment fields delivered by the provider and embedded in the merchant's page, usually through iframes or equivalent mechanisms.
Visually, the checkout may look native. Technically, the elements receiving sensitive data are controlled by the provider.
This model aims to combine an integrated experience with reduced direct exposure of the merchant to card data.
But details matter. How the elements are delivered and which parts of the page participate in collection influence security scope and responsibilities.
Are iframes and hosted fields always the same thing?
No.
An iframe is a technique for embedding content. Hosted fields are a product pattern in which specific fields are hosted by the processor.
A checkout can use a single iframe containing the entire payment area or multiple frames for separate fields.
What matters for security and compliance is where the collection elements actually originate and how the merchant's page can affect the flow.
What is direct post?
Direct post is a design in which the merchant's page participates in creating the fields that collect data, but the browser sends that data directly to the processor.
This seems similar to hosted fields because the merchant's backend may not receive the PAN.
From a scope perspective, however, there is an important difference: the merchant's page is directly involved in accepting card data.
The PCI Security Standards Council explicitly distinguishes these models in its eligibility criteria.
Why does the origin of the elements matter?
Because a compromised page can manipulate the payment path.
Even if data is sent directly to the PSP, a malicious script in the merchant's environment can change the DOM, replace fields, intercept information, or change the user's destination, depending on the architecture.
Outsourcing processing does not remove the need to secure the website.
PCI DSS v4.x strengthens controls for e-commerce pages precisely because the merchant's environment can affect the security of the flow even when processing is outsourced.
Does a hosted checkout eliminate PCI DSS?
No.
Outsourcing collection and processing can reduce the applicable scope, but it does not mean having no responsibilities at all.
Eligibility for questionnaires and requirements depends on the technical design and all applicable criteria.
For example, the PCI SSC explains that, in certain scenarios eligible for SAQ A, payment page elements must come from validated providers and other criteria still need to be met.
Website security, redirect integrity, and vulnerabilities remain relevant.
What changes with PCI DSS v4.x for e-commerce?
The standard increased its focus on script attacks and payment page compromise.
Even merchants that outsource processing may have obligations related to the security of the website that influences the journey.
This matters because “I do not store cards” has never meant “my page cannot be attacked.”
Checkout begins before the first sensitive field.
Which model reduces technical scope the most?
Generally, the more collection and processing are delegated to a validated provider, the smaller the surface directly controlled by the merchant tends to be.
A full redirect usually transfers more operational responsibility for the payment page to the provider than a form built by the merchant itself.
But any scope claim must be validated against the actual design and current PCI DSS criteria.
Architectures that look similar can have different implications.
Does an embedded checkout convert better?
There is no universal answer.
Keeping consumers on the same domain can reduce the feeling of disruption and give more control over the experience. That can help in some journeys.
On the other hand, a highly optimized hosted page may convert better than a poorly built custom checkout.
Conversion depends on trust, performance, payment methods, clarity, errors, authentication, mobile, latency, and familiarity.
The technical model is just one variable.
Does redirecting always increase abandonment?
Not necessarily.
If the provider is fast and reliable and the transition is clearly explained, the impact may be small.
In some markets, users are familiar with bank pages, wallets, and methods that naturally open another environment.
The bigger problem is surprise.
When consumers do not understand why they left the page or cannot get back, friction increases.
Does mobile change this decision?
Yes.
Smaller screens make any disruption more noticeable. At the same time, wallets and banking apps already create cross-app flows naturally.
An embedded checkout needs excellent keyboard behavior, autofill, validation, focus management, and responsiveness.
A hosted checkout needs to load quickly and preserve context on return.
Testing only on desktop is not enough.
Who controls the error experience?
With a custom checkout, the merchant can control messages, visual state, and recovery in considerable detail.
With a hosted checkout, part of the experience depends on the provider.
This can be an advantage when the PSP already handles dozens of edge cases, or a disadvantage when the merchant needs highly specific language and logic.
A good decision considers how many errors truly need customization and how much maintaining that logic internally costs.
Who controls new payment methods?
Hosted pages can generally add new methods with less work for the merchant when the provider already supports them.
With an embedded checkout, each method may require additional integration, components, states, and testing.
For international operations, that difference grows quickly.
The company must decide whether to own each method's presentation layer or delegate part of it.
What about Pix?
Pix works well in both models.
A custom checkout can generate a payment request, display a QR code, and update the page state. A hosted checkout can encapsulate that journey.
The difference is still responsibility for UX and integration.
In both cases, confirmation should happen on the server through events and queries, rather than relying solely on the browser.
What about 3DS?
3DS adds another layer to the experience.
With a custom checkout, the integration must carefully manage redirects, iframes, challenges, returns, and states.
A hosted checkout can abstract away part of that flow.
This abstraction reduces complexity, but also gives less control over the details of the journey.
How does tokenization change an embedded checkout?
Tokenization lets the browser deliver the credential directly to a secure environment and return a token that the backend uses for subsequent operations.
This reduces the need for the merchant's server to handle the PAN.
Even so, it is necessary to evaluate how the page collects the data and which components are in scope.
Tokenization does not automatically make every implementation equivalent to a fully hosted page.
Does a custom checkout mean storing cards?
No.
It is possible to maintain a custom experience without storing PANs, using provider components and tokenization.
Storing cards yourself is a much more demanding decision and is rarely necessary for most merchants.
The distinction between “I control the interface” and “I control the vault” is fundamental.
How does checkout affect portability between PSPs?
A checkout tightly coupled to a PSP's proprietary components can increase switching costs.
A fully custom checkout with a tokenization abstraction can also face lock-in if the tokens are not portable.
Portability needs to be analyzed in layers: interface, token, authentication, API, and operational data.
Having multiple PSPs in the backend does not guarantee portability if card collection depends on a single provider.
Can multi-PSP work with a hosted checkout?
It can, but the routing decision works differently.
If each PSP has its own page, the merchant may need to select the provider before redirecting the customer.
This reduces routing opportunities after the session has been created.
An independent checkout layer can retain more freedom of choice, provided tokens and credentials are usable on the desired routes.
Can hosted fields work with Smart Routing?
Yes, provided the tokenization strategy allows it.
If the generated token works only with one PSP, the route is implicitly chosen at collection.
If there is a vault or tokenization with adequate portability, routing can remain flexible.
This is one of the most important questions for multi-PSP architecture.
What happens if the checkout provider goes down?
A hosted page creates a direct dependency on the provider's availability during the journey.
A custom checkout also depends on the PSP for tokenization and processing.
The difference is where the failure appears and what alternatives exist.
If the operation uses multiple PSPs, it is worth planning whether another path can be offered when the primary component is unavailable.
Is checkout failover possible?
Yes, but it is more complex than changing an API URL.
The customer may already have entered data in a component. A token may belong to the provider that failed. Authentication may be in progress.
Safe failover needs to understand state and avoid asking customers to repeat steps unnecessarily.
How do you measure checkout performance?
Loading time is only the beginning.
It is useful to track time until the form is interactive, time to tokenization, intent creation latency, authentication time, component error rate, and total time to confirmation.
This breakdown shows whether the problem is in the page, SDK, PSP, or authorization.
What is a good fallback strategy?
Fallback should be planned by stage.
If the SDK does not load, there may be another component. If tokenization fails, another method may be needed. If authorization fails technically, another route may exist.
There is no generic fallback called “try again.”
Each stage carries different risks.
How do you handle analytics without capturing sensitive data?
Checkout needs metrics, but analytics scripts should not have unnecessary access to payment fields.
Hosted components help create isolation.
Even so, third-party tags and scripts on the page must be governed because they can compromise the experience or the website.
Minimization is a good rule: each script should have only the access it needs.
What changes for A/B testing?
A custom checkout offers more freedom to experiment with field order, messages, layout, and components.
With a hosted checkout, the testing surface is smaller.
But more freedom also means more responsibility for not breaking accessibility, security, and conversion.
Not every UX experiment belongs in the sensitive-data collection area.
Does a hosted checkout speed up time to market?
Often, yes.
A company can launch methods and countries using a ready-made page, avoiding the need to build every variation from the start.
This is valuable for product validation.
Later, the operation may decide to bring parts of the experience in-house if the added control justifies the cost.
Architecture can evolve.
When does an embedded checkout make more sense?
It makes sense when UX control is strategic, the team has engineering and security capabilities, and the operation needs to integrate payment deeply into the journey.
Complex marketplaces, products with specific flows, and companies optimizing conversion at scale may value that control.
But the benefit needs to outweigh the ongoing maintenance cost.
When does a hosted checkout make more sense?
It makes sense when speed, reduced complexity, and method coverage are priorities.
It is a good option for companies that do not want to turn the payment page into their own infrastructure product.
It can also be the best choice for new markets where the merchant does not yet know all the local specifics.
Is there a middle ground?
Yes.
Hosted fields, embedded elements, SDKs, and modular components create a spectrum between a full redirect and a fully custom form.
That spectrum allows you to choose which responsibilities to retain.
That is why the decision should not be binary based solely on how the screen looks.
How do you choose objectively?
Start with business requirements.
How much UX control is truly necessary? How many methods and countries need support? How mature is the security team? Is there a multi-PSP strategy? Does token portability matter? How much time is available to launch?
Then compare the operating cost of each design.
The most technically flexible solution may be the most expensive organizationally.
Should security alone decide?
No, but it should be a nonnegotiable requirement.
It is possible to build a secure custom checkout and a poorly integrated hosted checkout.
The point is that each design creates different responsibilities.
The decision needs to bring together product, engineering, security, payments, and compliance.
How do you document checkout architecture?
A good diagram should show the browser, merchant domain, third-party components, card data destination, tokenization, backend, PSPs, 3DS, and webhooks.
If the team cannot identify exactly where the PAN travels, there is a gap in understanding.
Documentation should also indicate which scripts can affect the page.
Does the browser return confirm payment?
No.
Redirecting back to the store is an experience mechanism.
Financial confirmation should be obtained through an API, webhook, or server query, depending on the method.
Trusting browser parameters as the final source creates room for inconsistency and manipulation.
How do you handle a user who closes the hosted page?
The backend needs to keep the intent alive and reconcile its state independently of the session.
The user may pay and close the tab before returning.
If the system relies on the return to mark success, it will miss legitimate sales.
This principle applies to any checkout with redirects.
How does checkout connect to the rest of the infrastructure?
It is the entry point, not the whole system.
After collection come authentication, authorization, capture, webhooks, refunds, reconciliation, and chargebacks.
The ideal architecture lets the checkout experience change without forcing all those domains to know the details of the visual component.
Can embedded and hosted checkouts coexist?
Yes.
A company can use a custom checkout in its primary market and a hosted page in specific countries. It can retain hosted fields for cards and redirect to wallets. It can use hosted payment links in support channels and embedded checkout in e-commerce.
The choice can be made by channel and method, rather than for the entire company.
What is the central difference between the two models?
Embedded checkout prioritizes control of the experience and deep integration, taking on greater technical responsibility.
Hosted checkout prioritizes delegation and speed, accepting customization limits and greater dependence on the provider's experience.
Hybrid components sit between the two extremes.
The best choice makes explicit who controls each part of the flow.
Checkout is infrastructure, not just a screen
The payment page defines how credentials are collected, where risk is evaluated, how authentication appears, which PSP enters the flow, and what data falls under the merchant's responsibility.
That is why choosing between embedded and hosted checkout should be treated as an architectural decision.
A good interface converts. A good architecture also protects, scales, provides visibility, and allows evolution without turning every PSP change into a complete rebuild of the journey.