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.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.
High-level flow
- Your server creates a short-lived onboarding session (Partner Key).
- Your client mounts the returned URL in an iframe (helper below, or raw
<iframe>). - The form runs on TagadaPay’s origin, themed with your partner branding.
- On success / exit, the iframe notifies the parent via
postMessage. - 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.Session rules
- Entity id is the durable resume key —
entityIdon the session response is the same id used by dashboard?resume=and abandoned-recovery emails. Store it. ons_…is short-lived — regenerate with the sameentityId/externalRef/accountIdif the merchant abandons and comes back (createSessionis idempotent on those keys).- One active embed URL per session — do not share URLs across merchants.
allowedOrigins— required for iframe embedding; Tagada setsContent-Security-Policy: frame-ancestors …from this list. Origins must be HTTPS (localhost allowed in test).
/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 A — JS helper (recommended)
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.
4. After the merchant completes
Embed submit feeds the same entity / TPA pipeline as dashboard / SDK applications:- The application lands in the ops entity inbox (same as
applications.create). - After Tagada promotes / assigns: payfac partners call
tpas.provision(tpaId); CRM-only wait for operator assignment, then mint a key withpartners.processing.enroll({ accountId }). - Subscribe to partner webhooks for status changes if you do not want to poll.
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
allowedOriginsthat match the page hosting the iframe (scheme + host + port). - Ignore
postMessageevents whoseoriginis not the Tagada onboard host. - Do not put Partner Keys, long-lived secrets, or raw session minting in mobile/WebView JS bundles.
- Treat
session.urlas 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 shelltpas.create()(403 payfac_required). - Payfac: you can mix
requirements.update/documents.uploadwith the embed on the same TPA, thenprovision.
