Delivery models

One governed core. Four ways to ship payroll.

Ledra Pay is embedded-first — but the same certified engine, evidence chain and API power a full app you can run for direct customers, a bureau console for managed-service providers, and a white-label of any of them. You choose how much surface to own; the payroll system of record is always Ledra.

Land

Embedded SDK

Drop tenant-scoped web components into your own product. Narrow, origin-bound embed tokens; safe to run cross-origin in an untrusted page. Your brand on the screen, our engine underneath.

for: platforms & HRIS Embedding guide →

Own the customer

Enterprise app

The full single-organisation payroll console — multi-site, cost-centre aware, with role-based access (viewer · preparer · approver · admin) and segregation of duties enforced in the API and the UI.

for: direct customers Open the enterprise app →

Leverage

Bureau console

A multi-client command center: aggregate KPIs, a client roster and a pay-run pipeline across an entire portfolio of client companies. Built on the partner-portfolio API.

for: payroll BPOs / MSPs Open the bureau console →

Resell

White-label

Re-skin any surface with a brand config — the app chrome and every SDK component re-theme from your palette through --ledrapay-* tokens. Ship payroll under your own name.

for: channel & resale How white-label works →

At a glance

Who runs what

Model	Buyer	Runs payroll for	Auth tier	Surface
Embedded	Platform / vendor	Their customers, inside their product	Embed token (tenant + component + origin scope)	Your app, our components
Enterprise	One organisation	Themselves (multi-site)	User token (role + cost-centre scope)	enterprise.ledrapay.com
Bureau	Payroll BPO / MSP	Many client companies	Partner key (portfolio), first-party only	bureau.ledrapay.com
White-label	Any of the above	As above	As above + brand config	Rebranded

The sandbox console is the try-before-credentials demo — it auto-connects to demo data and showcases the SDK.

The security spine

Three credential tiers, narrowing scope

Every model uses the same three-tier model — each tier is the one above, narrowed:

partner key — full portfolio, server-side only (bureau, minting)
↓ mints
user token — one tenant + a role + a cost-centre/site data scope (enterprise: RBAC, segregation of duties)
↓ or
embed token — one tenant + a component allowlist + optional employee & origin pin (embedded, cross-origin-safe)

Roles enforce segregation of duties. A preparer builds pay runs but cannot approve; an approver approves and finalises but cannot prepare; only admin does both. The gate is in the API (the real boundary) and mirrored in the components (buttons hide/disable). Data scope filters by cost-centre — and fails closed: a scoped user against a data source that can't attach the cost-centre dimension sees nothing, never unfiltered data. Full detail in the API reference.

White-label

Re-skin in one config

The apps accept a brand via ?brand=<slug> (or an inline JSON) that sets the chrome and writes brandable --ledrapay-* tokens at :root. Because every component inherits those tokens into its shadow tree, one line re-themes the whole surface — no component changes.

https://enterprise.ledrapay.com/?brand=acme
→ chrome + all mounted components adopt Acme's palette

Bureau components are partner-scoped — first-party only. ledrapay-portfolio-dashboard, ledrapay-client-list and ledrapay-pipeline-board read the whole portfolio and authenticate via a session-gated same-origin proxy that injects the partner key. They must never be embedded in an untrusted page or handed a token — unlike the 28 tenant-scoped components, which are safe to embed anywhere with a narrow embed token.