Stripe Connect for Platforms: The Complete Setup Guide

Key Takeaways
- •Express is the right account type for most platforms: Custom looks appealing and consumes far more ongoing engineering than anyone estimates
- •Charge type decides dispute liability, and under destination charges a dispute lands on you even though the connected account got the money
- •Onboarding and identity verification is where users drop out, so surface exactly what is outstanding in your own interface
- •Check the supported country list against where your users actually live before committing to Connect
- •If payouts are not core to your product, a platform that handles them natively removes months of engineering plus permanent compliance work
Stripe Connect is what you reach for when money needs to move from a buyer to somebody who is not you. Marketplaces, platforms, anything with affiliate or creator payouts. It is also the point at which a simple payments integration becomes a compliance project, and most of the difficulty is in that second part rather than in the code.
This guide covers which account type to choose, what onboarding actually requires, and the operational realities that are not obvious until you are live.
The question Connect answers
Standard Stripe moves money from a customer to you. Connect moves money from a customer to a third party, with you taking a cut and controlling the experience.
If that is not your situation, you do not need Connect and adding it will cost you complexity for nothing.
The three account types
This is the decision that shapes everything downstream, and it is expensive to change later.
Standard
The connected user has their own full Stripe account and relationship with Stripe. They onboard through Stripe, see the Stripe dashboard, and handle their own disputes and compliance.
You get: minimal liability, almost no support burden, fastest path to launch.
You give up: control of the experience. Your users see Stripe branding, manage things in Stripe's dashboard, and can in principle disconnect.
Right when: your connected users are established businesses who probably already have Stripe, and the payout relationship is not the core of your product.
Express
A middle path. Stripe handles onboarding and identity verification through a hosted flow, provides a lightweight dashboard, and takes on compliance. You control the payment flow and set fees.
You get: Stripe carries the identity verification and regulatory burden, with a reasonably branded experience.
You give up: some interface control, and you pay a per-account monthly fee for active accounts.
Right when: your users are individuals or small businesses, which describes most creator platforms, marketplaces and affiliate programs. This is the default answer for most people reading this.
Custom
You own the entire experience. Your users never see Stripe. You collect all onboarding information through your own interface and pass it via API.
You get: complete control of the experience.
You give up: a great deal. You are responsible for collecting verification data, handling the ongoing requirements as they change, and building all the account management interfaces yourself. Stripe applies additional review before approving Custom.
Right when: the payout experience is genuinely core to your product and you have engineering capacity to maintain it indefinitely.
The honest recommendation for most teams is Express. Custom looks appealing in a design review and consumes far more ongoing engineering than anyone estimates.
Charge types, which is the second structural decision
How money flows determines who is liable for disputes and who appears on the customer's statement.
Direct charges. The charge is created on the connected account. They are the merchant of record, they appear on the statement, and they own the dispute. You take an application fee.
Destination charges. The charge is created on your account and funds are transferred to the connected account. You are the merchant of record and you own the dispute liability. The customer sees your name.
Separate charges and transfers. You charge, then transfer independently, possibly splitting across several recipients or on a different schedule.
The dispute point is the one that surprises people. Under destination charges, a dispute lands on you even though the connected account received the money, and you may have already paid it out. Build for that case before it happens rather than after.
For a platform where the buyer thinks they are buying from you, destination charges are usually right. For a marketplace where the buyer knows they are buying from an independent seller, direct charges usually are.
Onboarding is the hard part
Every connected account has to satisfy know-your-customer requirements. This is not optional and it is where users drop out.
What is typically required:
- Legal name, date of birth and address for individuals
- Business registration details for companies
- Beneficial ownership information above certain thresholds
- Government identification, often with a document upload
- Bank account details for payouts
- A tax identifier depending on the country
The requirements vary by country and by the account's activity, and they can change after onboarding. An account that was fully verified can later be asked for more information when it crosses a volume threshold.
The operational consequence: you need to handle the state where an account is created but not yet able to receive payouts. Your interface has to show what is outstanding and how to resolve it. Platforms that skip this end up with support tickets from users who do not understand why their money is not arriving.
The account object exposes what is missing. Surface it in your own interface rather than leaving users to guess.
Payouts
Connected accounts can be paid on a schedule Stripe manages, or you can control timing manually.
Points that matter:
- New accounts have a longer initial hold while risk is assessed. Communicate this at onboarding or every new user will assume something is broken.
- Payout timing varies by country, sometimes considerably.
- Failed payouts happen, usually from incorrect bank details, and need a visible resolution path.
- Negative balances occur when a dispute or refund hits an account with insufficient funds. Decide in advance whether you cover it or carry it forward.
Fees, and who pays them
Connect adds cost on top of standard processing: per-account charges for active Express and Custom accounts, payout fees varying by country and method, and additional fees for cross-border transfers and currency conversion.
The decision that needs making early is whether your take rate absorbs these or passes them on. Both are defensible; discovering the answer after launch is not, because changing it later reads as a price increase.
Compliance obligations that are yours
Using Connect does not make you a passive conduit.
- Tax reporting. Depending on jurisdiction and volume you may have information reporting obligations for the people you pay. Stripe offers tooling for some of this; the obligation is still yours to understand.
- Sanctions and prohibited businesses. You are responsible for who you onboard, and Stripe's list of prohibited businesses applies to your connected accounts.
- Your own terms. You need an agreement with connected accounts covering fees, payout timing, dispute handling and termination.
When Connect is the wrong answer
Worth stating plainly, because it is a substantial build.
- If you only pay a handful of people, manual transfers are cheaper than the integration and its maintenance.
- If payouts are not core to your product, a platform that handles payouts natively removes the entire problem. Building and maintaining a Connect integration is months of engineering plus ongoing compliance work that never ends.
- If your recipients are in countries Connect does not support, you need another rail regardless.
That third point catches people. Check the supported country list against where your users actually are before committing, not after.
What to build before launch
1. A clear onboarding status interface showing exactly what is outstanding.
2. Handling for accounts that are created but not payout-enabled.
3. A decision and a mechanism for negative balances.
4. Dispute handling that accounts for money already transferred out.
5. Communication about first-payout timing.
6. Your platform agreement with connected accounts.
Items one and two account for most of the support load in the first months, and both are routinely left until after launch.
For the underlying payment mechanics, how online payments work covers authorisation, settlement and disputes. For payout policy specifically in an affiliate context, affiliate payout strategies covers thresholds, holding periods and reversals, and cross-border payments covers what international payouts really cost.
Written by Jamal Brooks
Jamal is a product engineer at Affiliateo who writes about payments, integrations, and technical best practices.


