Merchants meet a hosted payment page, or HPP, whenever the provider serves the payment screen from its own domain and the shopper is sent there to pay. The buyer leaves the store, enters card details on infrastructure the merchant does not own, and returns with a result.
From redirect to return, step by step
The merchant's server creates the order and calls the provider's API with an amount, a currency and a reference. The provider returns a one-time URL. The buyer is redirected to it, enters card details, clears any authentication step, and is sent back to a success or failure page the merchant nominated.
In parallel, the provider posts a server-to-server webhook carrying the real outcome. The two paths take different amounts of time, and only one of them is reliable.
Trust the webhook, not the return URL
A buyer can close the tab, lose signal, or be returned by a browser that drops the parameters. A merchant that marks orders paid on the return redirect will ship goods it was never paid for and lose orders it was paid for.
Treat the redirect as a cue to show a screen and the webhook as the record. Anything still pending after a few minutes should be reconciled against the provider's API rather than written off as abandonment.
Why card data never reaching you is worth money
Nothing sensitive touches merchant servers, so the PCI DSS obligation falls to the lightest self-assessment level, and a store breach cannot expose card numbers that were never held. For a small team that is months of audit work avoided, and it is the main reason an HPP is usually the fastest route to accepting cards at all.
An embedded checkout removes the redirect but hands part of that responsibility back.
Flows that require a redirect regardless
Bank-based methods send the payer to their own bank to approve, and most wallets open their own domain or app. A merchant selling into markets where an alternative payment method carries the bulk of volume will be running redirects either way, so the visual break is not something a hosted page uniquely introduces.
Questions to settle with the provider before signing
How far the page can be styled, and whether it can be served from a merchant subdomain. Which languages and payment methods it renders. Whether a card token can be stored for repeat billing. How timeouts and duplicate submissions are reported. And what happens when a buyer clicks back midway — the abandoned path is the one nobody tests and every finance team eventually asks about.