Stripe Connected Account

Two properties decide what your books contain

If you only read one thing about connected accounts, read the fee payer property.

Stripe gives controller.fees.payer two values you can set at creation. With account, "The connected account pays all Stripe fees directly to Stripe, inclusive of payment processing fees". With application, "The Connect platform pays all Stripe fees, inclusive of payment processing fees".

That is the difference between processing fees being an expense on your platform’s books and being invisible to them entirely. A platform on the first setting has no processing fee to record for those payments, because it never paid one. A platform on the second carries the whole card-processing cost of the marketplace as its own operating expense, and usually prices for it somewhere in what it charges sellers.

The second property is controller.losses.payments. Set to application, Stripe says "Your platform is responsible for negative balances" and manages credit and fraud risk on the connected account, which it notes "requires you to review and acknowledge your responsibilities in the Dashboard". Set to stripe, "Stripe is liable when this account can’t pay back negative balances resulting from payments", with the caveat that "Your platform is still liable for a negative balance on your platform account."

One property tells you whether an expense exists. The other tells you whether a bad month at one seller becomes your bad month. Both are set once, at account creation, by whoever wrote the integration.

Account types are the old vocabulary for the same thing

Standard, Express and Custom are still the words most people use, and Stripe still supports them, but its documentation now treats them as legacy. The page describing them opens by saying the information "applies only to platforms that already use legacy connected account types", and directs new platforms elsewhere.

Each name is shorthand for a fixed set of the four properties. Standard maps to losses.payments stripe, fees.payer account, requirement_collection stripe, and dashboard type full. Express maps to losses.payments application, fees.payer application, requirement_collection stripe, and dashboard type express. Custom maps to losses.payments application, fees.payer application, requirement_collection application, and dashboard type none.

Read down the fees column and the practical meaning of the three names becomes obvious. On Standard, the seller pays Stripe. On Express and Custom, the platform does. Everything else about those names is about onboarding effort and who sees a dashboard.

There is one wrinkle worth knowing if you are reconciling fees and the numbers look inconsistent between older and newer accounts. Stripe notes that creating an account with type=express or type=custom sets fees.payer to application_express or application_custom rather than plain application, and that "This difference denotes a variation in Stripe fee billing behavior when your platform is using Direct charges." Two accounts that look identically configured can bill differently depending on which way they were created.

Dispute liability does not follow the platform automatically

Chargebacks are where the ownership question gets expensive, and the answer depends on both the account configuration and the charge type.

Stripe’s own comparison puts fraud and dispute liability on the connected account for direct charges on Standard accounts, and on the platform for destination charges. For Express and Custom accounts it puts that liability on the platform outright.

So a platform can be in the position of never seeing the sale, never holding the money, and still owning the dispute. That combination is worth checking before it happens rather than after, because the accounting entry for a dispute you are liable for is nothing like the entry for one you merely processed.

Stripe also flags a pricing consequence of the legacy setup: using direct charges on legacy Express or Custom accounts "charges connected accounts directly at standard sticker rates rather than billing the platform", and it points platforms that want pricing control toward destination charges instead.

What you cannot change after the fact

Three things about a connected account are set once, and each of them has been the reason a platform had to migrate sellers onto new accounts.

The type is fixed: "After you create a connected account, you can’t change its type." The dashboard is fixed: Stripe states you cannot change controller.stripe_dashboard.type on an existing connected account, and that "To change a connected account’s dashboard, you must create a new Account object." The country is fixed too, and Stripe repeats that for Standard, Express and Custom accounts separately.

Migrating your integration to controller properties is a different and much lighter matter. Stripe says the migration "is optional", that the properties are "fully backwards compatible", and that existing accounts have the matching properties set automatically, so you can move incrementally. Reading a connected account’s controller values is therefore something you can do today regardless of how the account was created, which makes it the honest way to answer "who pays the fees on this one".