Who this section is for

Business owners, product, solution architects, and engineering leads choosing how their platform brings PayMongo accounts onto its books. Read this page before you build — the path you pick determines who signs up, where the form lives, how much code you write, and how white-labeled the experience feels.

Overview

A parent account can onboard a child account in one of two ways. Both produce the same outcome — an activated child account linked to your platform via an Account Linking relationship — but they differ in who creates the account and where the user experiences PayMongo.

At a glance

Both paths converge: identity verification, update, and activation are the same. See Quick start for the API flow.

Invite

The parent sends an invitation to a prospective child by email or by existing PayMongo Account ID. The recipient creates or owns the account; your platform gains access through the resulting Account Linking relationship once accepted.

When to choose this path

Use Invite when:

• The recipient already operates their own PayMongo account, or will operate it independently after onboarding.
• You want a clean audit trail of mutual agreement before the parent acts on their behalf.
• Your platform does not need to embed the onboarding UI; a PayMongo-hosted signup is acceptable.

Scenarios at a glance

The full invitation lifecycle (states, transitions, who triggers each) is documented in Linked accounts.

Create an account

The parent calls the Accounts API to create a child account directly. The Account Linking relationship is created in the same call. The child has no independent PayMongo sign-up step — the parent owns onboarding from end to end.

When to choose this path

Use Create an account when:

• You want full control over the onboarding UI, copy, and pacing.
• Your platform is the recipient's primary (or only) entry point to PayMongo.
• You are scaling onboarding for high volumes of users you already know.

Two configurations

Create an account supports two configurations. Both create the account and the Account Linking relationship in the same call. The difference is whether the recipient ultimately gets their own PayMongo Dashboard access.

How it works

flowchart LR
  A[Parent: POST /v2/accounts] --> B[Account + Account Linking<br/>relationship created]
  B --> C[Identity verification]
  C -->|passed| D[Update account]
  D --> E[Activate account]

Each step is documented in Quick start. For identity verification, you can choose between the Hosted identity verification microsite (PayMongo handles selfie and ID capture) and the API-only flow (you submit the images directly).

Dashboard access

Once a child account is activated, its authorized representative can get their own PayMongo Dashboard access for that account. This is on by default for every child account.

Here are the steps for representative to login:

1. Go to the PayMongo Dashboard login page and enter the email address recorded as the authorized representative of the child account.
2. PayMongo emails them a 6-digit OTP code, which they enter to verify their identity.
3. They set a password and accept PayMongo's terms. This step shows the account they are claiming, including its Account ID, so they can confirm it is the right one.
4. They can optionally set up a passkey, then go straight into PayMongo Dashboard.

If your product needs the recipient never to see PayMongo, dashboard access can be disabled for your child accounts. The request process, the self-serve roadmap, and FAQs are documented in Disable dashboard access.

How to decide

Pick the path that matches who creates the account and how much of the onboarding flow your platform wants to own.

flowchart TD
  Q1{Who should create<br/>the account?}
  Q1 -->|The recipient| INV[Invite]
  Q1 -->|The parent, via API| CRE[Create an account]

Most platforms standardize on one path:

• Invite — two-sided platforms and partner-driven products. Recipient signs up or accepts; PayMongo is part of the recipient's experience.
• Create an account, with Dashboard access (Default) — referral setups where you bootstrap the account but the recipient eventually operates it from their own PayMongo Dashboard.
• Create an account, without Dashboard access — fully white-labeled embedded experiences. Recipient never sees PayMongo.

Required information per account type

The required fields are the same across paths. The difference is who fills them in.

See Quick start for the exact field-by-field requirements, and the Appendix for enum values.

Next steps

• Quick start — implement the chosen path end-to-end.
• Opt-in features — request auto-configuration, partner KYC reliance, per-account capabilities, or disabling dashboard access.
• Best practices — FAQs and tips for each onboarding stage.