Key concepts

Walk away with a clear mental model of parent and child accounts, the lifecycle, and the terms you will use throughout this section.

Who this section is for

Business owners, C-level leaders, product, engineering, and compliance teams. Read this page first to understand how Onboarding-as-a-Service works as a building block — how it lets your platform extend PayMongo to your own users so you can grow your ecosystem without rebuilding KYC, KYB, or payments yourself.

Overview

Onboarding-as-a-Service is the foundation building block for building your platforms on PayMongo. Use it to create accounts for the users in your ecosystem — merchants, sellers, riders, freelancers, consumers — and link them to your platform as child accounts. Once activated, each child can use the full PayMongo product suite the same way a stand-alone account would.

📘

Scope

This section is the developer guide for the Create an account path. The Invite path's mechanics (linking-request lifecycle, by-email and by-Account-ID flows) live in the canonical Linked accounts page. The concepts on this page apply to both paths.

How the model fits together

Creating a child account automatically links it to your platform as a child account. It goes through the same compliance work any other PayMongo account does — KYC for the authorized representative, KYB for the business when the child is a merchant. The flow is flexible: most platforms use PayMongo's standard identity verification, while approved partners with their own KYC capability can use Partner Verification to submit their own results.

Onboarding-as-a-Service covers the lifecycle from account creation to activation. Once activated, the child operates as a regular PayMongo account, and your platform can transact on its behalf through Linked transactions.

🚀

Coming soon

Onboarding-as-a-Service will also cover requesting additional capabilities — wallets beyond the defaults, card acceptance, e-wallets, and more — on behalf of a child via API. See Account capabilities.

🚀

Coming soon — multi-association linked accounts + policy contracts

The linking model is moving from "one parent per child" to multi-association: an account can hold many relationships at once, each one its own record (mr_xxxx) with a parent role and a child role. Each relationship will be governed by an explicit policy contract that both parties agree to. The contract scopes what the parent may do on that specific relationship — for example, view linked transactions only, or CRUD on payment acceptance. See Policy contracts for the full model.

Glossary

TermDefinition
Parent accountThe role an account plays as the initiator of a relationship — typically your platform. With multi-association (Coming soon), an account is parent only within a specific relationship, not globally.
Child accountThe role an account plays as the recipient of a relationship. Identified by an org_* ID. Can be of type merchant or consumer. With multi-association (Coming soon), an account is child only within a specific relationship.
Account type — merchantA business account. Requires KYC of the authorized representative and KYB of the business. Shown as Merchant in the dashboard.
Account type — consumerAn individual account. Requires KYC of the account holder. No KYB. Shown as Non-business in the dashboard.
Authorized representativeThe natural person who owns or is authorized to act for the account. KYC is performed against this person.
KYCKnow Your Customer. Identity verification of the authorized representative.
KYBKnow Your Business. Business risk and document review for merchant accounts.
Onboarding pathOne of two ways to bring a child onto your platform: Invite (invitation-led; the recipient creates or owns the account) or Create an account (API-led; the parent creates the account). See Onboarding paths.
InvitationA linking request the parent sends as part of the Invite path. Identified by lr_xxxx. Moves through pending, accepted, or cancelled.
Identity verificationThe KYC step that validates the authorized representative's selfie and government-issued ID. Required before activation unless Partner Verification is enabled for your platform.
ActivationThe step that opens the child account for live transactions. Once activated, account details can no longer be edited through the API.
Activation statusThe current state of the child account. See Activation statuses below.
CapabilityA product the child account is enabled to use (QR Ph, wallets, cards, e-wallets, payouts). Lives on the child. See Account capabilities.
Linking requestThe technical term for the invitation object created by the Invite path. Identified by lr_xxxx. Synonymous with Invitation.
Relationship (Coming soon)A single linked-account record. One direction only — parent → child — identified by mr_xxxx. Each direction is its own record. See Policy contracts.
Policy contract (Coming soon)The agreement attached to a relationship that scopes what the parent may do on that link. Authored by the parent, accepted by the child, amended mutually, terminable by either party. See Policy contracts.
Linked transactionA transaction created by a parent on behalf of an activated child, using the Account-Id header. Documented under Linked transactions.
📘

Key guide — capability and policy contract are different

Capability lives on the child account and determines which products the child can use. Policy contract (Coming soon) lives on the relationship and determines what the parent may do on that link. The parent's effective permissions on a link are the intersection of both. See Policy contracts for the full model.

Account lifecycle

flowchart LR
  A[Create account] --> B[Identity verification]
  B -->|passed| C[Activate account]
  B -->|failed| B
  C --> D[Activated]
  D -.->|may later be declined<br/>by post-activation review| E[Declined]

Activation is automatic once all requirements are in place. After activation, the child is also subject to a post-activation risk review by PayMongo. It is possible — though uncommon — for an account to be declined after activation as part of this review. If your account is declined post-activation, contact [email protected] to raise a dispute.

There are two retry points to design for during onboarding:

  1. Identity verification fails. Restart identity verification and submit another attempt. Repeat until the result is passed before activating.
  2. Activation reports missing fields. Update the missing fields, then call Activate again.

Activation statuses

The Accounts API uses these statuses:

StatusMeaning
pendingThe child account exists but has not yet been activated. It cannot transact.
activatedThe child account is live and can use the products it has been provisioned with.
declinedThe child account is not allowed to transact. Activation was not granted, or the account was declined during post-activation review.

For the general account-setup state machine across PayMongo (live Dashboard view), see Account setup.

What activation provisions

Activation follows the same default pattern as a normal PayMongo account.

Child account typeDefault capabilities at activation
merchantWallet + QR Ph (P2M) as a payment-acceptance method, plus Dashboard access for the authorized representative
consumerWallet (supports QR Ph (P2P) transfers; no payment-acceptance method is provisioned), plus Dashboard access for the authorized representative

Additional payment methods and other products are not granted by default.

🚀

Coming soon

  • Parent-initiated capability requests via API — your platform will be able to request additional capabilities (cards, e-wallets, other rails) on behalf of a child directly through the Accounts API.
  • Self-serve toggle dashboard access for child accountsDisabling dashboard access currently requires creating a support request. Self-serve flow is coming soon (Q4 2026)

See Account capabilities for what is supported today and the full roadmap.

Opt-in features

Some Onboarding-as-a-Service features are off by default. Each carries its own eligibility requirements and regulatory considerations and must be reviewed before PayMongo enables it for your platform. Each has its own dedicated page with the full criteria.

FeatureWhat it does
Auto-configurationApplies your default capability set to every new child upon successful activation.
Partner VerificationSubmit your own KYC results (and soon KYB) for approved partners with licensed processes.
Account capabilitiesEnable specific products on a child beyond the activation defaults.

Related pages


Did this page help you?