Merchant Onboarding API with KYB

A merchant onboarding API for platforms that need hosted or embedded onboarding sessions, requirement tracking, and KYB-style activation flows inside the product.

Teams searching merchant onboarding or KYB APIs usually need a programmable path to create a merchant, launch onboarding, track requirements, and know when the account is payments-ready.

Flint exposes merchant onboarding under the public merchant API instead of hiding activation behind an internal-only support flow.

Platforms can launch hosted or embedded onboarding sessions and poll the current requirement state through the same merchant surface.

Developer bootstrap and merchant onboarding work together, so teams can go from first key to payments-ready merchant without switching systems.

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

Your platform needs to create merchants, launch onboarding, and track outstanding requirements through the public API.

Platform 2

You want hosted or embedded onboarding sessions instead of sending every merchant into a disconnected manual setup flow.

Platform 3

You need a clear machine-readable signal for when a merchant is payments-ready and which requirements are still due.

Scenario 1

Hosted activation flow

Create a merchant onboarding session and send the merchant through a hosted activation path without building the requirement UI yourself.

Scenario 2

Embedded platform onboarding

Keep onboarding inside your product with an embedded session while still relying on Flint for processor requirement handling.

Scenario 3

Requirement polling and readiness

Poll onboarding status to see whether charges, payouts, and requirements are complete before you enable live flows.

Scenario 4

Bootstrap to payments-ready

Move from first API key and sandbox access into full merchant activation without switching to a separate onboarding system.

Choose Something Narrower When

Use developer bootstrap alone when the only immediate goal is to mint the first API key and not finish merchant activation yet.

Use dashboard-only onboarding when your product does not need to embed or orchestrate activation inside the software itself.

Use broader platform pages when onboarding is only one part of a larger multi-merchant payments architecture decision.

Implementation References

Reference the platform-level surfaces

Merchants API

Read and update merchants, begin onboarding, create onboarding sessions, and poll onboarding status.

Developer Bootstrap

Bootstrap the first merchant, optional processor onboarding, and initial API key over the public API.

API & Agent Onboarding Guide

Walk through the bootstrap and onboarding flow when you do not have Flint auth yet.

Explore activation, sandbox setup, and adjacent platform flows

These pages connect merchant activation to the wider developer onboarding and platform payments model.

Payments API for POS Integrators

Useful when merchant onboarding is one part of a broader software-platform payments rollout.

Sandbox Environments for Payment APIs

Use this when you need to validate onboarding-adjacent flows in isolated environments before launch.

Payment API

Go broader when onboarding is one part of the wider payment and platform architecture decision.

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.