Skip to content

What is a hosted payment page? Hosted vs integrated checkout, PCI scope and branding

What a hosted payment page is, how it compares with an integrated checkout, what it means for PCI scope, and how to brand it and bring buyers back.

Published 5 min read

Hand-drawn illustration of a shop page with an arrow redirecting to a separate checkout page with a padlock, a logo and brand colour swatches, next to a person pointing at it
On this page
  1. How does a hosted payment page work?
  2. Hosted payment page vs integrated checkout
  3. What does a hosted payment page mean for PCI compliance?
  4. What does the hosted checkout handle for you?
  5. Can you embed a hosted payment page in an iframe?
  6. How to brand a hosted payment page
  7. How to bring buyers back after payment
  8. Two details worth getting right
  9. Summary

A hosted payment page is a checkout page that your payment provider runs on its own domain. Instead of building a card form on your site, you send the buyer to the provider's page; they pay there, and come back to you afterwards. Card details are typed into the provider's page, not yours — which is the main reason most small and cross-border merchants start with a hosted payment page rather than an integrated checkout.

This guide explains how a hosted payment page works, how it compares with an integrated checkout, what it means for your PCI scope, and how to make a hosted checkout look like your own and bring buyers back to your site.

How does a hosted payment page work?

  1. Your server creates an order with the amount and currency and gets back a checkout URL.
  2. You redirect the buyer to that URL.
  3. The buyer pays on the hosted page — card, wallet, 3D Secure, retries, all handled there.
  4. The buyer returns to your return_url, and your server is notified by webhook.

On KukoPay that is one call:

curl -X POST "https://api.kukopay.com/v1/orders" \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: $KUKOPAY_API_KEY" \
  -d '{
    "out_trade_no": "ORD_20261104_0001",
    "amount": 2990,
    "currency": "USD",
    "subject": "Premium plan",
    "notify_url": "https://shop.example.com/webhooks/kukopay",
    "return_url": "https://shop.example.com/orders/{OUT_TRADE_NO}/complete"
  }'

The response's checkout_url opens the hosted checkout on checkout.kukopay.com. The quickstart walks through it end to end. With no code at all, a payment link opens the same hosted page.

Hosted payment page vs integrated checkout

Hosted payment pageIntegrated checkout
Where the buyer paysThe provider's pageA form on your own site
Card dataNever touches your serversPasses through or near your environment
PCI scopeGenerally the lightestWider, and yours to maintain
Build effortOne API call and a redirectCard form, wallets, 3D Secure and error states to build and keep working
Look and feelYour name, logo and colour on a standard layoutFully custom
New payment methodsAppear without code changesEach one is integration work

An integrated checkout wins when the page itself is your product and you have the team to own it. For most merchants — and especially those selling across borders, where the method mix differs by country — the hosted payment page is the better trade: the provider keeps the card form, the wallets and 3D Secure working, and you keep shipping your product.

What does a hosted payment page mean for PCI compliance?

PCI DSS applies to anyone who accepts card payments, but how much of it applies depends on where card data flows. With a hosted payment page the card number is entered on the provider's page and never reaches your servers, which generally keeps a merchant on the lightest form of self-assessment. It does not remove PCI obligations altogether — the page that sends buyers to the checkout is still yours to keep secure — so confirm what applies to you with your provider and the PCI Security Standards Council's guidance.

On KukoPay, merchants never handle card details: buyers enter them in the hosted checkout, they are never shared with the merchant, and merchants may not send them to the platform. Even the sandbox card form uses the test number only in the browser to choose a scenario — see test credit card numbers.

What does the hosted checkout handle for you?

  • Payment methods — cards, Apple Pay, Google Pay, Alipay, WeChat Pay and PayPal, showing only those enabled on your account and available for the order;
  • 3D Secure challenges, when the issuer asks — see what is 3D Secure;
  • Declines and retries — a decline leaves the order pending and the buyer can try again on the same page; see card decline codes explained;
  • Switching methods safely — an unfinished wallet or 3DS payment is cancelled before a new one starts, so a buyer cannot be charged twice;
  • Languages — English, Chinese, Japanese, Korean and German, chosen with &locale= on the URL;
  • Receipts — a printable receipt for every paid order, see payment receipts.

Can you embed a hosted payment page in an iframe?

Not on KukoPay. The checkout is a full page you redirect to, and it refuses to be framed by other sites. That is deliberate: a payment page inside someone else's frame is how clickjacking works, and wallet and 3D Secure steps need to take over the window anyway. Redirect the buyer, and bring them back with return_url.

How to brand a hosted payment page

A hosted payment page should still look like you — buyers who recognise the seller complete payment more often and dispute less. In the dashboard, open Business name & branding:

SettingWhat it does
Public nameThe name buyers see. Leave it empty to use the company name from verification
LogoShown at the top of the checkout
Brand colorA #RRGGBB colour for buttons and accents
  • Checkout preview shows the real checkout with your unsaved settings, on Desktop or Mobile, before you save.
  • Changes apply to newly opened checkout pages straight away, in both the sandbox and live.
  • Each app can override the account default — useful when one account runs a second brand. Settings left empty fall back to the account's.

How to bring buyers back after payment

  • Use placeholders in return_url. {TRADE_NO} and {OUT_TRADE_NO} are replaced with the order's values, so one URL tells you which order came back.
  • What the buyer sees. After paying, the checkout shows the receipt, then returns the buyer to your site after about 5 seconds; they can also return at once, or stay. Reopening an already-paid link only shows the receipt.
  • The return is not the result. A buyer may close the page and never come back, and a redirect can be faked. Fulfil on the verified webhook — return_url vs notify_url explains why.

Two details worth getting right

  • Set the checkout's lifetime. A checkout URL works for 24 hours by default. If your own system cancels unpaid orders sooner, pass expires_at so the page closes first — otherwise a buyer can pay an order you have already cancelled. See create an order.
  • Keep the URL out of analytics. The checkout_url carries a short-lived token; do not record the full address in third-party analytics or public logs.

Summary

  • A hosted payment page is a checkout the provider runs; you redirect the buyer there and get the result by webhook;
  • compared with an integrated checkout it is far less to build and generally keeps your PCI scope at its lightest;
  • KukoPay's hosted checkout handles methods, 3D Secure, retries, languages and receipts, and is a full-page redirect, never an iframe;
  • brand it under Business name & branding — public name, logo and colour, with a desktop and mobile preview and per-app overrides;
  • bring buyers back with return_url placeholders, set expires_at when your own timeout is shorter, and fulfil on the webhook.

Try it in the sandbox

Create a merchant account and request a test key. The sandbox needs no business verification.