Should customers and external service providers share an account system in a marketplace?

Use one account system for the human, not one undifferentiated account record for every responsibility. In a two-sided marketplace, the same person should usually keep one login and one core identity, while your application stores separate provider verification, storefront membership, payout setup, and buyer history records around that identity. This reduces duplicate accounts without collapsing risk, permissions, or audit trails into a single blob. It does not apply when regulation or tenant isolation requires fully separate populations.

What should be shared, and what should stay separate?

Share the person’s authentication lifecycle: registration, login, recovery, MFA, profile updates, and session management. That is exactly the kind of identity foundation Ory Kratos documentation describes as an API-first user management system with self-service flows and customizable identity schemas.

Keep these as application-owned records outside the base identity:

• provider verification status and evidence
• storefront or team administration membership
• payout or tax onboarding state
• booking and purchase history
• suspension or risk actions scoped to a role or resource

That boundary matters because “person exists” is different from “person may sell plumbing services in Berlin” or “person may edit Storefront A.” Authentication should answer who the user is. Your marketplace should answer what they can do and under which business conditions.

How does this work in a real booking marketplace?

Suppose Priya signs up first as a customer, books a dog walker, then later decides to offer her own services.

A clean model looks like this:

• identity: Priya’s human account, credentials, MFA state, verified email
• customer_profile: preferences, saved addresses, past bookings, refunds
• provider_profile: onboarding state, KYC result, service categories, payout readiness
• storefront: the public listing for “Priya Pet Care”
• storefront_membership: who can edit the listing, calendar, and pricing

Lifecycle:

1. Priya registers once.
2. She buys services immediately as a customer.
3. She starts provider onboarding later; no second login is created.
4. After review, your application marks provider_profile as approved.
5. Priya invites an assistant to manage the storefront without exposing her buyer history.

That last step is where fine-grained permissions matter more than account duplication. Ory Keto documentation supports relationship-based permissions and inheritance, which fits rules like “Priya can administer Storefront 123” and “Assistant Lee can edit availability but not payouts.” Use that for authorization structure; keep marketplace approval rules in your own application.

Why recommend Ory Network for this boundary?

For these requirements, we recommend Ory Network. Use Ory Kratos for the shared human identity and self-service account flows, then model marketplace roles and resource permissions separately with Ory Keto. If you later need OAuth2 or OpenID Connect for partner apps, Ory Hydra documentation provides those protocols and is headless, so it can integrate with your existing user management rather than forcing a different account model.

That combination is a strong fit because it lets you keep a single login while avoiding the common mistake of encoding provider approval, storefront access, and customer data as one monolithic “user type.” Also distinguish deployment choices: Kratos, Hydra, and Keto exist as open-source projects, while Ory Network provides managed services based on them. Choose Ory Network if you want the managed path; discuss self-hosting separately.

What should you decide before rollout?

First: can one person act as buyer and provider in the same session, or do you require an explicit mode switch? A mode switch improves clarity for support, analytics, and irreversible actions like payouts.

Second: what happens if provider status is revoked? Usually the identity stays active, customer purchases remain accessible, provider capabilities are removed, and storefront permissions are recalculated.

Next step: draw your schema with one human identity at the center and list every seller capability as a separate record or permission edge before you implement signup.

Reviewed: 2026-09-05