Skip to main content
By default, a Yuno Payment Link redirects the customer to Yuno’s hosted checkout on a Yuno domain: 
https://checkout.sandbox.y.uno/payment?session={session_id}
There, the checkout SDK loads from a *.y.uno origin and calls Yuno services directly. White-labeling lets you serve that same hosted checkout under your own domain (e.g. pay.yourbrand.com) with the Yuno branding removed and every subsequent request — SDK bundle, assets, API, WebSocket, 3DS — routed through your infrastructure.
This is the hosted-checkout counterpart to the SDK-level White Label page. It reuses the same apiUrl / assetUrl overrides, applied to the Payment Link redirect instead of a direct <script> integration.

​
How it works

Two things make the hosted checkout render under your domain:
  1. A proxy under your domain that forwards checkout, asset, API, and WebSocket traffic to the matching Yuno upstreams — so the browser only ever talks to your origin. See White Label Proxy Server for a reference implementation and local test harness.
  2. A rewritten redirect URL. Yuno’s API returns the default checkout.<env>.y.uno URL, so your backend intercepts and rewrites it before serving it to the customer: swap the domain for yours and append apiUrl / assetUrl query parameters that tell the SDK where to route requests and load assets.
Yuno API returns →  https://checkout.sandbox.y.uno/payment?session={session_id}

Your backend rewrites to →
  https://pay.yourbrand.com/payment?session={session_id}&apiUrl={your_api_url}&assetUrl={your_asset_url}

​
URL rewrite steps

Perform these on your backend, on the redirect URL returned by the Yuno API:
  1. Intercept the API response. Catch the payload containing the default checkout.<env>.y.uno redirect URL generated by Yuno.
  2. Replace the base domain. Swap checkout.<env>.y.uno for your white-labeled domain (e.g. pay.yourbrand.com).
  3. Append the required query parameters. Add apiUrl and assetUrl. The SDK relies on these overrides to route all subsequent payment requests and to load visual assets through your infrastructure instead of Yuno’s.
  4. Register your domains with Yuno. Send your checkout domain, apiUrl, and assetUrl to your Yuno account representative so they can be added to the Payment Link security allowlist before you go live (see Security).

​
Parameter reference

ParameterTypeDescription
sessionStringThe session identifier generated by the Payment Link API. Keep it unchanged.
apiUrlStringBase URL the SDK uses to route and forward payment requests (REST + WebSocket) and the checkout BFF.
assetUrlStringBase URL the SDK fetches its script bundle, images, stylesheets, and other frontend assets from.
Both apiUrl and assetUrl support a sub-path (the SDK preserves the prefix on every downstream request), so they can point at a proxy mounted under a path — e.g. https://pay.yourbrand.com/checkout.
Typically apiUrl and assetUrl are the same origin — the proxy under your domain. The SDK uses the value verbatim — it only appends its own version segment (e.g. …/v1.9/main.js) when assetUrl doesn’t already end with one.

​
Security

The apiUrl / assetUrl parameters are part of a link that reaches the customer’s browser, so they are attacker-influenceable — and assetUrl drives the origin the SDK script loads from. An unvalidated value would be remote-script execution against the checkout. Yuno gates them accordingly:
  • Host allowlist. An override is honored only when its host exactly matches a domain Yuno has approved for your Payment Links. The feature is off by default — unknown hosts are ignored and the checkout falls back to the Yuno origin.
  • https: only, exact host match (no subdomain wildcards), with WHATWG URL parsing (so tricks like https://approved@evil.com resolve to evil.com and are rejected).
Provide your domain, apiUrl, and assetUrl to your Yuno account representative and confirm they are allowlisted before distributing white-labeled links. Until then the overrides are ignored (checkout stays on the Yuno domain), and a browser may block the un-allowlisted redirect.

​
What gets de-branded

When a valid white-label override is active, the hosted checkout shell is de-branded:
  • The browser tab <title> and meta are neutral (no “Yuno”).
  • The loader element and its DOM event use the neutral sdk-payments-* surface (matching the SDK White Label rename).
  • The “Secure by Yuno” tag is hidden.
  • No *.y.uno request originates from the page — the SDK bundle, assets, checkout BFF, REST/WebSocket, and 3DS all resolve through your apiUrl / assetUrl origin.

​
Requirements

  • A hosted checkout build with white-label support (checkout shell on @yuno-payments/sdk-web ^1.9.1 or later — the same release that shipped the SDK White Label rename).
  • Your checkout domain, apiUrl, and assetUrl allowlisted by Yuno.
  • A proxy under your domain forwarding to the Yuno upstreams — see White Label Proxy Server.

​
Verifying the setup

Load a white-labeled Payment Link and confirm in browser DevTools:
  1. Network tab — no requests to any *.y.uno host (SDK bundle, checkout BFF, REST, WebSocket, 3DS). All traffic goes to your domain.
  2. The browser tab title and loader are de-branded, and the “Secure by Yuno” tag is absent.
  3. A payment (including a 3DS challenge, if applicable) completes end-to-end and returns to the checkout under your domain.

​
See also