Skip to main content

Embed onboarding (iframe)

Available. Mint a session with your Partner Key, mount the returned URL in an iframe (or via onboarding.js). The form is partner-branded from your partner profile. Contact your account manager if branding fields are empty.
Drop TagadaPay’s full KYB / onboarding form inside your own app, styled with your logo and colors. Merchants never leave your product chrome. TagadaPay still runs requirements, document intake, underwriting hooks, and provisioning — the same systems as the dashboard form. This is not a white-label of the entire TagadaPay dashboard. A full branded dashboard host (appHost / partner CRM branding) is a separate product. Embed onboarding is only the KYB form, in an iframe.

When to use which route

  • Prefer C when you want our form UX (smart-fill, document kinds, validation) without rebuilding KYB.
  • Prefer B when you already collect every field/document in your own UI and only need to push bytes + values.
  • Prefer A when you want zero UI work and accept a TagadaPay-branded redirect.
Processing partners and CRM-only partners can both use Route C. Economics and acquirer assignment still follow the same rules as Accounts (TPAs).

High-level flow

  1. Your server creates a short-lived onboarding session (Partner Key).
  2. Your client mounts the returned URL in an iframe (helper below, or raw <iframe>).
  3. The form runs on TagadaPay’s origin, themed with your partner branding.
  4. On success / exit, the iframe notifies the parent via postMessage.
  5. Your backend continues with the usual TPA lifecycle (retrieve / provision / webhooks).

1. Create a session (server)

Authenticate with your Partner Key. Create (or resume) a session bound to the merchant / TPA you are onboarding.
Never create sessions or expose session tokens in browser-callable code with your Partner Key. Mint the session on your backend, pass only session.url (or a short-lived client token) to the frontend.

Session rules

  • Entity id is the durable resume keyentityId on the session response is the same id used by dashboard ?resume= and abandoned-recovery emails. Store it.
  • ons_… is short-lived — regenerate with the same entityId / externalRef / accountId if the merchant abandons and comes back (createSession is idempotent on those keys).
  • One active embed URL per session — do not share URLs across merchants.
  • allowedOrigins — required for iframe embedding; Tagada sets Content-Security-Policy: frame-ancestors … from this list. Origins must be HTTPS (localhost allowed in test).
Resume examples:
Abandoned recovery emails for embed drafts remint a fresh embed URL for the same entity (not a new application). Dashboard /apply drafts keep using /merchant/requests/new?resume={entityId}.

Draft vs submitted (same as tagadapay.io/apply)

createSession creates a real tpa_entities row immediately (status: draft) and returns its entityId. Mid-form autosave updates that row. Drafts are not in the TagadaPay ops inbox — operators only see applications after the merchant submits (status: submitted). Until then the entity id is only a resume / abandoned-cart key, identical to the Tagada dashboard onboarding form.

2. Mount the iframe (client)

Option B — raw iframe + postMessage

postMessage envelope

Events

Always verify event.origin is https://dashboard.tagadapay.io before trusting the payload.

3. Branding

The embed uses your partner branding from the TagadaPay partner profile (same fields as CRM / invite emails): Configure branding in the partner admin (or via your TagadaPay contact). No per-session theme override is required for the default path — the session inherits the partner’s branding automatically.
Embed onboarding is form-only chrome: no TagadaPay dashboard navigation. That keeps the iframe feeling native inside your product while the full white-label dashboard remains a separate enablement.

4. After the merchant completes

Embed submit feeds the same entity / TPA pipeline as dashboard / SDK applications:
  1. The application lands in the ops entity inbox (same as applications.create).
  2. After Tagada promotes / assigns: payfac partners call tpas.provision(tpaId); CRM-only wait for operator assignment, then mint a key with partners.processing.enroll({ accountId }).
  3. Subscribe to partner webhooks for status changes if you do not want to poll.
Idempotent resume: if the merchant returns later, createSession with the same entityId (preferred) or accountId / externalRef returns a fresh URL for the same tpa_entities draft when the previous token expired. Mid-form progress is stamped on the entity (onboardingProgress) — identical to the Tagada dashboard form — so abandoned reminders and iframe remounts land on the same step.

5. Security checklist

  • Mint sessions server-side with the Partner Key only.
  • Pass allowedOrigins that match the page hosting the iframe (scheme + host + port).
  • Ignore postMessage events whose origin is not the Tagada onboard host.
  • Do not put Partner Keys, long-lived secrets, or raw session minting in mobile/WebView JS bundles.
  • Treat session.url as a capability URL — do not log it in public analytics.

6. Relation to API-only intake (Route B)

  • CRM-only: prefer partners.processing.applications.create({ accountId, … }) (same payload as merchant applications) or the embed — not shell tpas.create() (403 payfac_required).
  • Payfac: you can mix requirements.update / documents.upload with the embed on the same TPA, then provision.
Do not dual-submit the same document from both paths unless you intend to replace it — prefer one writer per requirement.

See also