Stripe Connect account types, explained

Stripe Connect is Stripe's product for platforms and marketplaces that route payments between sellers, customers and other parties. Each business that accepts payments through a platform has a connected account. How that account is set up decides who the business deals with, who can see the Stripe Dashboard, who collects verification information and who covers losses.

For years these setups were known as three account types: Standard, Express and Custom. Stripe's documentation now describes those as legacy account types. It recommends describing accounts by their individual behaviors instead, using controller properties or, in the newer Accounts v2 API, account configurations. This page explains both, and why it matters to a merchant whose payments run through any software provider.

The three legacy account types

Stripe's documentation still describes the three types for platforms that already use them.

Standard accounts

A Standard connected account is a conventional Stripe account. Stripe's documentation says the account holder has a direct relationship with Stripe, can log in to the full Dashboard and can process charges on their own. Stripe handles onboarding and identity information gathering, and communicates directly with the account holder about account issues, such as requests for verification information.

Express accounts

With an Express account, Stripe handles onboarding and identity verification, but the account holder mainly interacts with the platform. The platform can set charge types and payout settings. The account holder gets the Express Dashboard, a lighter version of the Dashboard, to manage personal information and see payouts, and to manage disputes and refunds only if the platform enables those features.

Custom accounts

A Custom account is almost completely invisible to the account holder. The platform is responsible for all interactions, including collecting the information Stripe needs. Stripe's documentation states that Custom account holders do not have access to the Dashboard and that Stripe does not contact them directly.

Who carries fraud and dispute liability

Stripe's comparison of the legacy types sets out where fraud and dispute liability sits:

• Standard: the connected account for direct charges, and the platform for destination charges.
• Express: the platform.
• Custom: the platform.

Stripe also notes that the choice of account type determines the platform's liability for fraud, abuse, negative balances and identity verification, and that an account's type cannot be changed after it is created.

Controller properties: the current way to describe an account

Stripe now recommends using controller properties instead of account types. Each property describes one behavior, which allows combinations the three types did not cover. The main properties are:

• losses.payments: whether Stripe or the platform is liable when the account cannot pay back negative balances from payments.
• fees.payer: whether the connected account pays Stripe fees directly or the platform pays them.
• requirement_collection: whether Stripe or the platform collects updated information when verification requirements are due or change.
• stripe_dashboard.type: whether the account can use the full Stripe Dashboard, the Express Dashboard or no Dashboard.

Each legacy type maps to a set of these values. A Standard account, for example, maps to Stripe covering payment losses, the account paying its own fees, Stripe collecting requirements and full Dashboard access. Custom accounts map to the platform covering losses, the platform collecting requirements and no Dashboard. Stripe states that migrating to controller properties is optional and that existing accounts have the matching properties set automatically.

Accounts v2 and account configurations

Stripe's newer Accounts v2 API goes a step further. A v2 account uses configurations, which Stripe describes as role-based sets of functionality. The most common are:

• merchant: lets the account accept payments from customers.
• customer: lets the platform charge the account as a customer.
• recipient: lets the account receive funds transfers.

An account can hold more than one configuration, and Stripe's example request also sets which party collects fees and which covers losses. The idea is the same as controller properties: responsibilities are set one by one rather than bundled into a named type.

Why this matters to a merchant

You do not need to know the API to benefit from these terms. They answer practical questions about any software that touches your payments:

• Is the Stripe account yours, in your business's name, or is it held or controlled by a platform?
• Can you log in to the full Stripe Dashboard and see your own payments, disputes and payouts?
• When Stripe needs information about your business, does it contact you directly, or does a platform sit in between?
• Who is responsible for negative balances and disputes on your payments?
• Whose name and support details appear on receipts? Stripe's receipts documentation notes that for direct charges, receipts use the connected account's own email, branding and public details settings.

If you cannot answer these questions about a provider you use, ask them in writing before you connect anything. A merchant who owns their Stripe relationship directly can read their own account notices and answer Stripe's questions themselves, which is the clearest position to be in during any processor information request.

These setups are also not a way to move responsibility for what you sell onto someone else. Whatever the account structure, the business described to Stripe should be the business actually taking the payments.

How Claddr connects to Stripe

Claddr connects to the merchant's existing Stripe account. Payments are processed by Stripe on the merchant's own account, the merchant keeps their Stripe Dashboard and payouts, and no funds are ever held by Claddr. It is compliance software, not a payment processor, and it is not affiliated with or endorsed by Stripe. The product page explains how the checkout and records fit together, the security page covers access and roles, and how Claddr's fees work explains how the transaction fee is deducted.

What this page does not cover

Stripe's Connect documentation is detailed and changes over time. Charge types, pricing for each setup, country availability and the exact API fields are outside the scope of this page. If you run a platform yourself, read Stripe's current documentation directly rather than relying on a summary. If you are deciding how to structure contracts with a platform or provider, speak to a qualified lawyer about your business.