How Connect Works
Connect is enabled per account. Talk to your Inflow contact to activate it on yours.
What you can build
| You are building | Example | You'll mostly use |
|---|---|---|
| A marketplace | Customers pay on your platform, you take a commission, and your hosts or vendors are paid out to their bank accounts. | On-behalf-of payments, platform fee, payout window |
| A SaaS platform or ERP | Your business customers accept payments through your software, each under their own name and balance. | Sub-merchant onboarding and KYB, fee overrides, connect.* webhooks |
| Cross-border money flows | A company group pays subsidiaries, vendors, or partners across currencies and countries. | Transfers, multi-currency settlement, bank payouts, virtual IBAN |
In every case the model is the same: your platform holds a single Inflow account and API key, and operates a fleet of sub-merchants (the equivalent of Stripe Connect's connected accounts).
What Connect is
Inflow Connect lets a platform onboard its own sub-merchants, accept payments on their behalf, take a configurable platform fee per transaction, and pay each sub-merchant out, all through a single Inflow API key.
Conceptually it mirrors Stripe Connect's separate accounts + on-behalf-of charges model:
- The platform (called the marketplace in the API, whatever your business model) holds a single Inflow account and a single API key.
- Each sub-merchant is a separate Inflow account (created via
POST /api/connect/accounts) with its own verification (KYC or KYB), its own balance, and its own payout destinations. - The platform operates on behalf of a specific sub-merchant on every payment / payout / customer call by setting an
X-On-Behalf-Ofheader. - Inflow automatically splits each payment between the sub-merchant (net), your platform fee, and Inflow's own fees.
When to use it
Pick Connect if any of the following are true:
- You operate a multi-account platform (marketplace, SaaS, ERP, vertical e-commerce, corporate group) and need a separate balance per account.
- You need to charge a per-transaction platform fee and have it auto-collected without writing your own ledger.
- Your sub-merchants each need their own payouts to a bank account, without signing up separately on Inflow.
If you only need to accept payments for your own business, you do not need Connect. Use the standard Inflow API.
How the money flows
Customer pays €100.00 (card, SEPA, Apple Pay, Google Pay)
│
├── Inflow processing fees €2.00
├── Your platform fee (2.5% + €0.30) €2.80
└── Sub-merchant balance €95.20
pending during the payout window (24h by default),
then available, then paid out to the sub-merchant's bank account- Incoming payments are pending during the payout window, then become available for payout. The window absorbs refunds and chargebacks; you control its length.
- Your platform fee settles into your own balance within minutes of capture. See Fees and Payouts.
- Payouts go to bank accounts (EUR, GBP, USD) or, optionally, to crypto wallets. See the Integration Guide.
Settlement currencies. Balances are held in the settlement currency that matches the payment rail: EUR payments settle as EURC, USD payments as USDC, with no automatic cross-currency conversion. You control which are enabled via
enabledCurrenciesin Marketplace Settings. This is an infrastructure detail: your sub-merchants see a balance and receive bank payouts in fiat.
Key concepts
| Concept | What it is |
|---|---|
| Marketplace | Your Inflow account, once Inflow has enabled Connect on it. Owns the API key, parents N sub-merchants. The API says "marketplace" regardless of your business model. |
| Sub-merchant | A separate Inflow account that belongs to your platform. Has its own verification, balance, and payout destinations. Sub-merchants cannot call the Inflow API directly; all access is mediated by their parent marketplace. |
| Connect settings | Per-marketplace configuration: fee rates, payout window, default redirects. See Marketplace Settings. |
X-On-Behalf-Of | HTTP header the marketplace adds to standard merchant routes (payments, payouts, customers, …) to act as a specific sub-merchant. See Acting on Behalf Of. |
| KYC / KYB | Per-sub-merchant identity verification. Individual sub-merchants go through KYC; business sub-merchants go through KYB. See KYC Flow. |
| Platform fee | Your take rate on each payment (marketplaceFee… fields in the API). Configured once per marketplace, overridable per sub-merchant; collected automatically. See Fees and Payouts. |
High-level flow
┌───────────────────────────────┐
│ Marketplace │
│ (single Inflow API key) │
└───────────────┬───────────────┘
│
POST /api/connect/accounts │
▼
┌───────────────────────────────┐
│ Sub-merchant created │
│ (verification pending) │
└───────────────┬───────────────┘
│
redirect to KYC URL → user verifies│
▼
┌───────────────────────────────┐
│ KYC / KYB approved │
│ → sub-merchant operable │
└───────────────┬───────────────┘
│
X-On-Behalf-Of: subId │ POST /api/payment
▼
┌───────────────────────────────┐
│ Customer pays │
│ → split: │
│ • sub-merchant (net) │
│ • platform fee │
│ • Inflow fees │
└───────────────┬───────────────┘
│
X-On-Behalf-Of: subId │ POST /api/payout
▼
┌───────────────────────────────┐
│ Sub-merchant payout │
│ (bank account / wallet) │
└───────────────────────────────┘What's next
- Connect Quickstart: request access and run your first end-to-end flow.
- Integration Guide: the full numbered API sequence, from setup to payout.
- Marketplace Settings: every field you can tune, plus the kill-switches Inflow controls.
- Sub-merchant Onboarding: create accounts, individual vs. business.
- KYC Flow:
nextUrl/nextStepscontract and how to drive verification to completion. - Acting on Behalf Of:
X-On-Behalf-Ofheader semantics and error codes. - Fees and Payouts: fee math, bearer model, payout window.
- Suspension and Lifecycle: pausing sub-merchants and the marketplace itself.
Updated 23 days ago
