Skip to main content

​
Overview

As an orchestrator, you can whitelabel the hosted Secure Payment page and hosted onboarding flow with your own colors, logo, and legal links. Orchestrator-level branding applies to all your linked client IDs and hosted onboarding. You can override it per linked client ID for Secure Payment. For Secure Payment, branding is resolved server-side and embedded in the GET /v2/secure-payments/:token response. Hosted onboarding uses the orchestrator-level branding when its link is validated.

​
Color tokens

Branding defines five color tokens. Each must be a 3- or 6-digit hex color. The page derives additional shades (hovers, borders, modal colors, and a light/dark scheme) automatically from these five values.
These are the theme-token names applied by the Secure Payment page. The underlying stored branding fields use Color-suffixed names — in particular surfaceBackground is stored as cardBackgroundColor (and pageBackground → pageBackgroundColor, primaryAction → primaryActionColor, and so on).
All three are relative paths that must start with /branding/ — they cannot be absolute URLs or protocol-relative, cannot contain a query (?) or hash (#), and cannot contain path traversal (..).
Asset files must be bundled with the deployed Secure Payment app under public/branding/{brand}/. There is no remote-URL fetch — a path that points to a missing file renders as broken branding, not a fallback. Coordinate logo/legal asset bundling with Request Network when onboarding your branding.

​
Request Network attribution

displayRequestBranding (boolean) controls whether the footer shows “Made easy by Request Network”. It defaults to off for orchestrator-branded payments. Set it to true to keep the attribution.

​
Secure Payment resolution priority

Branding is selected one row at a time, most specific wins:
  1. Client branding — if a linked client ID has its own branding row, it is used. Any field left unset in that row falls back to the Secure Payment defaults (not to the orchestrator’s values).
  2. Orchestrator branding — used only when the client ID has no branding row of its own.
  3. Secure Payment defaults (and the platform’s default legal links) — used when neither is set.
In other words, defining client-level branding replaces the orchestrator branding entirely for that client ID, so set every field you want at the level you use.

​
Manage branding

Use your x-orchestrator-key header for every branding operation. To target a linked client ID, include clientId in the JSON body when creating or updating branding. To get or remove its branding, pass ?clientId=cli_YOUR_CLIENT_ID. Omit clientId to manage orchestrator-level branding, which applies to all your linked client IDs and hosted onboarding. Creating branding where it already exists returns 409; use PATCH instead. PATCH updates only the fields you provide and cannot clear a field. DELETE is idempotent. Request Network must bundle logo and legal asset files into the deployed Secure Payment app. Contact the Request Network team to add or change those assets.

Secure Payment

The hosted page your branding themes.

Orchestrators overview

How orchestrators, client IDs, fees, and branding fit together.
Last modified on August 19, 2026