Who this section is for

Business owners, C-level leaders, product, and engineering teams scoping an Onboarding-as-a-Service integration. Use the shapes below to recognize whether your platform fits this product and what your integration will look like. Most real platforms blend two or three of them.

A common thread: white-labeled implementation

Across every shape on this page, the implementation is typically white-labeled. Your customers — sellers, riders, employees, travelers — interact with your brand and your UI. PayMongo powers the wallet, the payment rails, the identity verification, and the compliance underneath. They never need to know PayMongo is in the stack.

How much of the experience is white-labeled depends on which onboarding path you pick:

• Create an account, with dashboard access (default) — partially white-labeled. Your UI owns onboarding, and the recipient can also login to their own PayMongo Dashboard after activation. See Dashboard access.
• Create an account, but dashboard access disabled — fully white-labeled. The recipient never sees PayMongo's brand.
• Invite — not white-labeled. The recipient sees PayMongo on the signup page (new emails) or in their own PayMongo Dashboard (existing accounts). Best for two-sided onboarding and partner relationships.

Marketplaces

A marketplace onboards sellers (or service providers) to accept payments on its behalf. The marketplace handles checkout under its own brand; settlement and refunds flow through the sellers' linked child accounts. Sellers interact with the marketplace's UI, not PayMongo's — a fully white-labeled experience.

flowchart LR
  P[Marketplace] -->|Invite or Create an account| S[Seller child account]
  C[Customer] -->|pays via marketplace| P
  P -->|linked transaction| S
  P -.->|optional split| F[Marketplace fee]

• Onboarding path: prefer Invite when the seller already operates their own PayMongo account or will operate it independently after onboarding — no duplicate accounts. Use Create an account when the seller's experience should stay inside your marketplace's UI without any PayMongo branding.
• Capabilities: QR Ph by default. Add card acceptance or other payment methods via Account capabilities. A wallet if the seller manages its own balance.
• Operations after activation: create payments on behalf of the seller using either the Payments API or the seller-facing surfaces in Payment Channels (Payment Links, Pages, Checkouts). Optionally split payments between the marketplace fee and the seller.

Travel and booking platforms with multi-party splits

A travel agency or booking platform sells bundled trips — flights, hotels, transfers, tours, activities — and pays each downstream provider its share of the booking. One customer payment fans out to multiple recipients, plus the platform's own fee.

flowchart LR
  C[Customer] -->|pays for booking| TA[Travel platform]
  TA -->|hotel share| H[Hotel child account]
  TA -->|transport share| T[Transport child account]
  TA -->|tour share| O[Tour operator child account]
  TA -.->|platform fee| F[Platform fee]

• Onboarding path: Invite for hotels, transport operators, and tour operators — they typically operate their own PayMongo account or want to after onboarding. Use Create an account only for downstream providers your platform manages entirely.
• Capabilities: payment acceptance on the platform's side (cards, e-wallets, QR Ph). Each downstream provider needs a wallet to receive its share. Add card or other acceptance per provider via Account capabilities if a provider also wants to accept direct bookings.
• Operations after activation: the platform creates one payment on the customer's side via the Payments API, with the split distributed across multiple recipients at booking time. Each child account receives its share into its own wallet; the platform retains its fee.
• Why it's a distinct shape: most marketplaces split a single payment between platform and seller (two parties). Booking platforms regularly split between platform plus two, three, or more independent providers in a single payment.

SaaS with embedded payments

A SaaS product (booking software, salon platform, restaurant POS) lets its customers accept payments from their own end-customers, without those customers opening a separate PayMongo account. Merchants accept payments inside the SaaS interface — white-labeled — with PayMongo handling the rails, settlement, and compliance.

flowchart LR
  T[SaaS] -->|Create an account| M[Merchant child account]
  M -->|displays static QR Ph at counter| EC[End customer pays]
  T -.->|subscription fee| M

• Onboarding path: Create an account, embedded into the SaaS sign-up — fully white-labeled. Often paired with Auto-configuration so every new merchant activates with the same capability set.
• Capabilities: QR Ph (commonly used as a static QR displayed at the merchant's counter) plus the payment methods relevant to the merchant's industry. Add card or e-wallet acceptance via Account capabilities.
• Operations after activation: the SaaS creates payments on its merchants via Payments API or surfaces the Payment Channels (Links, Pages, Checkouts, QR Ph) for the merchant's own use.

Delivery and logistics

A delivery platform onboards riders or couriers, primarily to send them wages and tips. Riders rarely accept payments; they receive disbursements. The rider's wallet, transfers, and withdrawals live inside the platform's app — white-labeled — even though PayMongo powers the balance and money movement underneath.

flowchart LR
  L[Delivery platform] -->|Invite or Create an account| R[Rider child account]
  L -->|periodic payouts| R
  L -.->|tips routed| R
  R -->|rider controls funds| W[Wallet, transfers, withdrawals]

• Onboarding path: Create an account when the rider experience lives entirely inside the platform's own app (white-labeled). Invite for quick rollouts where a PayMongo-hosted signup is acceptable.
• Capabilities: a wallet for receiving payouts and tips. The rider controls the wallet — they can hold a balance, transfer to other e-wallets, or move funds to a bank from their own PayMongo wallet.
• Account type: usually consumer. Riders are individuals, not businesses.

Employee management and disbursement

An employer or HR platform onboards its employees to deliver salaries, allowances, benefits, or stipends. The accounts are fully managed by the platform — disable dashboard access so employees do not log into PayMongo independently. Payroll, benefits balances, and disbursement history all live inside the employer's own HR or finance app, fully white-labeled.

flowchart LR
  H[HR / employer platform] -->|Create an account| E[Employee child account]
  H -->|salary, allowance, benefits| E
  E -->|spend, transfer, withdraw| W[Wallet]

• Onboarding path: Create an account — fully white-labeled. The platform creates and operates the account on behalf of the employee.
• Capabilities: a wallet for receiving disbursements. No payment acceptance.
• Account type: usually consumer. Employees are individuals.
• Operations after activation: the platform funds employee wallets through Payouts and similar disbursement endpoints in Payment Channels.

Payment service providers and aggregators

Payment service providers, aggregators, and foreign banks that want to offer Philippine payment methods to their own users without becoming a Philippine-licensed payment processor. The aggregator's customers transact through PayMongo's rails, settled to child accounts under the aggregator. The aggregator's end customers experience the aggregator's brand — a fully white-labeled implementation where PayMongo is the Philippine payments engine running underneath.

flowchart LR
  AGG[Aggregator or foreign bank] -->|Invite or Create an account| CC[Customer child account]
  CC -->|QR Ph, cards, e-wallets| EC[End customer pays]
  AGG -.->|negotiated rates| PYM[PayMongo]

• Onboarding path: Invite when the aggregator's customer already has a PayMongo account; Create an account when the aggregator wants a fully white-labeled experience and stands up the account on their customer's behalf.
• Capabilities: typically QR Ph at scale, with cards and e-wallets added per child via Account capabilities. Aggregators commonly negotiate scheme-specific commercial terms with PayMongo before launch.
• Operations after activation: the aggregator creates payments on behalf of its customers using the Payments API. PayMongo handles the underlying rails, scheme onboarding, and compliance for the Philippine methods.
• Typical motivations: lower per-transaction rates on PH methods via PayMongo partnership; extending an existing international offering to include PH-local payment methods; offering QR Ph without operating direct scheme relationships.

Referrals and partner-driven onboarding

A platform refers users to PayMongo and gets them set up, but the users go on to manage their PayMongo accounts independently. The platform's role is bootstrap, not operations.

flowchart LR
  R[Referring platform] -->|Invite| U[User child account]
  U -->|operates independently| PD[Own PayMongo dashboard]

• Onboarding path: Invite — by email for new users (they sign up through PayMongo's invitation flow), or by Account ID for existing PayMongo users (Coming soon).
• Capabilities: handed off to the user after activation; the parent does not manage capabilities long-term.
• Operations after activation: the user operates from their own dashboard or with their own API keys.

Hybrid: platform-of-platforms

Larger products combine several of the above. A marketplace might run Invite for existing PayMongo sellers and new sellers who'll manage their own account, and Create an account for its own payroll wallets that should stay inside the company's HR app.

There is no special configuration needed — pick the path per onboarding case. The data model supports an account being both a child (of your parent) and a parent (of its own children), though most platforms operate one flat layer.

Where to go next