Multi-Tenant Payments API

A multi-tenant payments API for software platforms that need merchant-bound tenants, organization hierarchy, inherited settings, and safer auth boundaries across many accounts.

Teams searching multi-tenant payment APIs usually are not asking how to charge one customer. They are deciding how one software product should manage many merchant tenants, shared policy, merchant-bound auth, and rollout at platform scale.

Flint already treats the merchant as the payment and legal tenant, with optional organization hierarchy and inherited settings on the public API.

External API keys remain bound to one merchant while organization linkage and settings policies handle shared platform defaults, which is cleaner than loose cross-tenant impersonation.

That makes multi-merchant software easier to reason about because auth, tenant boundaries, and inherited controls live on the platform model itself.

Open the Technical Surface

Quickstart

Start with the first request.

API Reference

Open the REST surface.

Orders First

See the core model.

Benchmark

Compare developer workflows.

Use This Platform Shape When

Platform 1

One software product needs to manage many merchant tenants with explicit auth boundaries rather than shared global credentials.

Platform 2

Shared defaults should flow through org and policy hierarchy while payment execution stays merchant-bound.

Platform 3

New tenant rollout, settings inheritance, and merchant-scoped API access all need to fit one platform model.

Scenario 1

Merchant as payment tenant

Treat each Flint merchant as the legal and payment boundary while still attaching it to a wider platform hierarchy.

Scenario 2

Shared org defaults

Apply top-level configuration through organization and policy layers without flattening all tenants into one unsafe account.

Scenario 3

Safer platform auth

Keep external API keys bound to one merchant so tenant boundaries stay explicit even inside one SaaS platform.

Scenario 4

Predictable tenant rollout

Bring new merchants online with inherited settings and known auth rules instead of re-deriving the platform contract each time.

Choose Something Narrower When

Use organization-scoped settings when the main question is shared defaults and policy, not the full tenant architecture.

Use scoped API keys when the problem is narrow auth design for a single merchant rather than many tenants.

Use merchant onboarding when you already know the tenant architecture and just need to activate new merchants programmatically.

Implementation References

Reference the platform-level surfaces

Merchants API

Review the merchant as Flint's public payment tenant and how organization linkage appears on that model.

Settings API

Use effective settings and policy scopes when many tenants need shared defaults plus explicit overrides.

API Keys

Understand merchant-bound external API keys and the scope model that keeps auth boundaries explicit across tenants.

Explore tenant hierarchy, inherited policy, and merchant rollout

These pages connect Flint's tenant model to settings inheritance, merchant onboarding, and auth boundaries.

Organization-Scoped Settings API

Use this when the current problem is shared defaults and platform-level policy rather than the full tenant model.

Policy Inheritance API for Multi-Merchant Platforms

Go here when the architecture question turns from tenant boundaries into inheritance rules and override resolution.

Merchant Onboarding API with KYB

Useful when multi-tenant rollout also includes creating and activating new merchant tenants programmatically.

Next Step

Wire the platform boundary first

Define auth, merchant scope, and install flow first, then let the narrower payment and checkout pages sit underneath it.