Two ways to collect a payment
When a merchant builds a checkout flow, there are broadly two architectural choices. A hosted checkout sends the customer to a payment page hosted by the provider, either as a redirect or inside an iframe, where card and payment details are entered. An embedded form keeps the customer on the merchant's own page, with payment fields built directly into the merchant's site or app. Both approaches end with the same outcome, a completed transaction, but they get there differently, and that difference matters for conversion, control and compliance.
Conversion considerations
A hosted checkout, especially a redirect, introduces a visible handoff: the customer leaves the merchant's page and lands somewhere else before coming back. For some shoppers that break in continuity can raise doubt or add friction, particularly if the design of the hosted page looks noticeably different from the merchant's site. An embedded form avoids that jump, keeping the customer on a single page throughout. Whether this difference actually changes completion rates depends on the specific flow, the audience and how well the hosted page is styled to match the merchant's brand, so it is not something to assume without testing on your own traffic.
Control over design and flow
Embedded forms give a merchant more control over layout, field order, validation messaging and the surrounding page content, since the payment fields live inside pages the merchant builds. A hosted checkout limits how much of that experience the merchant can change; the provider defines the page structure, and the merchant typically works within theming or configuration options rather than full custom markup. This is the core trade-off: embedded forms offer more design freedom, hosted checkout offers less to build and maintain.
Compliance scope
The two approaches also differ in how much sensitive payment data touches the merchant's own systems. With a hosted checkout, card details are entered and handled on the provider's page, so they never pass through the merchant's servers or front-end code directly. With an embedded form, the fields render inside the merchant's own page, which generally means the merchant's environment is more directly involved in handling that data, even if the actual processing happens elsewhere. This difference in where data is entered and transmitted is a key reason merchants weigh compliance scope alongside conversion and design when choosing between the two.
Where omwio fits
omwio's hosted checkout gives merchants a payment page that sits outside their own front-end code, so the checkout step is handled on a page designed for that purpose rather than built and maintained by the merchant. For merchants operating through omwio's merchant panel, this means the checkout flow is available without the ongoing engineering work of building and updating payment forms in-house.
Making the choice
There is no single right answer between hosted checkout and embedded forms. The decision comes down to how much the merchant values owning the full visual flow against how much they want to limit how directly their own systems handle payment data, plus the engineering resources available to build and maintain a custom form over time. Testing both options against real traffic, where possible, is the most reliable way to see which trade-off fits a given business.
