How does the hosted checkout work?
The flow has four parties: your backend, the customer’s browser, Omno and the PSP. Your backend obtains an access token and creates a checkout session. Omno returns a session ID, a short-lived token and the checkout URL. Your backend passes the session ID and token to your frontend, which opens the checkout with the Web SDK.
The customer chooses a method and pays inside the checkout. Omno applies eligibility rules, routes the payment by your rules and, if the provider is unavailable or rejects it, moves it to the next provider in the rule. When the payment reaches a final state, Omno sends a webhook to your backend. You can also call Get Transaction Info to confirm. The browser may receive an update or a redirect, but that is for the interface only. Your ledger should move on the webhook.
Some outcomes resolve later. A status of PENDING or PENDING_3DS will settle asynchronously and arrive by webhook. A timeout may resolve after the customer has left. A customer who closes the checkout without paying produces no final webhook, so those sessions are reconciled through Get Transaction Info.
What are Omno forms?
Every provider asks for its own set of customer details. One wants an address, another a phone number, another a national ID number for local methods. Without help, a merchant has to collect every possible field up front, for every market, and then store and protect that data.
Omno forms remove that burden. You start a payment with the minimal data you already have. When the provider chosen by your routing rule needs more, the checkout shows an Omno form, collects the missing details from the customer and stores them on Omno’s side. The next payment from that customer goes through without asking again. You never build those forms, and you never manage that data in your own systems.
What can the checkout builder change?
The builder is part of the dashboard, so your payments or product team can change the checkout without asking developers for a release. It covers the layout and branding, the method categories and the order methods appear in, minimum, maximum and preset amounts, which routing applies, and which fields the checkout asks for.
The checkout is also personalised for each customer. Methods are shown by the customer’s country, currency and amount, and by their payment history, so a returning customer sees their saved card or account first.
Why does one checkout page convert better?
Shoppers finish a purchase when they see the way they already pay. A checkout that shows Apple Pay to an iPhone user in the UK, PIX in Brazil and Kaspi in Kazakhstan, in the store’s own colours, asks for less trust and less typing than a generic card form. Every extra step or unfamiliar screen is a chance to abandon the basket.
It also saves your team work. One page, one SDK and one webhook format cover every method and market, and design changes are made in the dashboard instead of in a release. Saved cards and accounts make repeat orders faster.
What changes versus a single PSP?
A checkout supplied by a single PSP shows that provider’s methods and nothing else. Adding a local method in a new country often means a second checkout, a second integration and a second set of webhooks. If the provider is down, the checkout is down.
The Omno checkout is provider-neutral. It shows the methods of every eligible provider for the customer in front of it, so a shopper in Brazil sees PIX and cards while a customer in Uzbekistan sees local cards and wallets, from the same integration. When a provider fails, the payment can move to another provider behind the same screen. Adding a provider changes what customers can select without any change to your frontend code.
You also keep one data model. Every payment, whichever provider processed it, appears in the same dashboard, the same exports and the same routing logs.
When should I use Card Fields, Direct Links or the iFrame instead?
Use Card Fields when your team builds its own checkout and wants to take cards on it. Three secure Omno card fields for card number, expiry and CVV sit inside your page, styled to match, and card data never touches your servers. Use Direct Links when you want your own buttons for local methods, wallets and crypto, with Omno routing each one across several providers of that method. You can use both on the same checkout. Use the iFrame when you want the hosted checkout but need it embedded in an existing page layout. For most new integrations the hosted checkout opened with the Web SDK is the fastest path, and it is the option Omno recommends.
Whichever option you choose, send as much customer context as you can when you create the session. Customer groups, customer verification levels (KYC levels in the API), whether the customer is verified in your system and how many previous transactions they have made all help your eligibility and routing rules pick the right provider. A checkout that knows it is serving a verified returning customer can offer saved cards and the providers you chose for repeat purchases. One that knows it is serving a first-time customer can follow a rule that sends first purchases to the providers you chose for them, or to providers with stronger checks. The more accurate the context, the fewer payments end up at a provider that was never going to approve them.