Stripe Connect

Stripe Connect lets platforms and marketplaces take payments for sellers and pay them out. Compare direct charges, destination charges, and separate transfers.

Updated October 1, 2026

Stripe Connect is Stripe's product for businesses that move money between several parties. A marketplace that pays sellers uses it. So does a SaaS platform that lets its customers take payments, and a delivery app that pays drivers. One Stripe account is the platform, and each business or person it pays is a connected account. Connect handles seller onboarding and identity checks, routes each payment, lets the platform keep a fee, and pays everyone out.

How Stripe Connect is set up

The platform and each connected account are regular Stripe accounts, each with its own pending and available balance. What changes is who is responsible for what. Stripe now describes that with configuration instead of fixed account types.

  • Accounts v2 gives each connected account configurations such as merchant, which can accept payments, recipient, which can receive transfers, and customer, which the platform can charge.
  • Accounts v1 with controller properties sets who pays Stripe fees, who covers negative balances, who collects verification details, and which dashboard the account gets. The dashboard options are full, Express, or none.
  • Standard, Express, and Custom accounts still work for existing platforms. Stripe treats them as legacy types and maps them to the same properties.

Connect also includes OAuth, which lets an existing Stripe account link to a platform or app. The app asks for read_write or read_only access, and the account owner approves it on a Stripe screen.

Stripe Connect charge types

The charge type decides where the payment lands, whose name is on the customer's statement, and whose balance pays for refunds and chargebacks.

  • Direct charges. The payment is created on the connected account and lands in its balance. Refunds and chargebacks come out of the connected account's balance. The platform earns an application fee set with application_fee_amount. Stripe suggests this type for SaaS platforms whose users sell to their own customers.
  • Destination charges. The payment is created on the platform, and Stripe transfers funds to one connected account straight away. Refunds, chargebacks, and Stripe fees come out of the platform's balance. Stripe suggests this type for marketplaces where the customer buys from the platform, such as ride sharing or home rentals.
  • Separate charges and transfers. The platform charges the customer first and creates one or more transfers to connected accounts later. Refunds, chargebacks, and Stripe fees come out of the platform's balance.

You can use more than one charge type on the same platform.

Separate charges and transfers

Separate charges and transfers decouple the payment from the payout to sellers. The platform takes the money, then decides who gets how much. Stripe calls it the more complex integration and recommends it only when you need it. The cases Stripe lists are:

  • One payment split across several sellers, such as a delivery order paid to both the store and the courier.
  • Several payments going to one seller.
  • A charge taken before you know who will be paid, such as a cleaning job assigned after booking.
  • Transfers sent before the payment arrives, or for more than the payment, such as a discount the platform absorbs.

Because transfers come out of your platform balance, you have to watch that balance. Setting source_transaction on a transfer ties it to a specific charge, so the money moves only once that charge's funds are available. transfer_group labels a charge and its transfers as one order.

Destination charges and separate charges and transfers only support cross-region money movement between some regions. Elsewhere the platform and connected account must be in the same region unless the charge uses on_behalf_of.

What application_fee_amount and on_behalf_of do

application_fee_amount is the platform's cut of a single charge, in the smallest currency unit. On a direct charge, it moves from the connected account to the platform when the payment is collected. On a destination charge, Stripe transfers the full amount to the seller and then sends the fee back to the platform.

on_behalf_of makes the connected account the business of record on an indirect charge. Stripe then settles the payment in the connected account's country, uses that country's fee structure, and shows the connected account's statement descriptor. Without it, the platform is the business of record.

Events on a Connect platform

Events for resources on connected accounts reach a webhook endpoint set to listen to Connected accounts. Each one carries a top-level account field with the connected account's ID. Platforms rely on these most:

  • account.updated fires when verification requirements or account status change.
  • account.application.deauthorized fires when an account with Dashboard access disconnects from your platform.
  • account.external_account.updated fires when a connected account's bank account or debit card changes, which can affect payouts.
  • payout.failed fires when a connected account's payout fails. Its bank account is disabled until updated, and no payouts go out meanwhile.

Destination charges and separate charges and transfers live on the platform, so their events arrive on an endpoint that listens to Your account. Treat both like any other webhook endpoint. Verify signatures, and check livemode, because a production Connect endpoint receives both live and test events.

Why Connect decisions matter

The charge type decides who absorbs losses. With destination charges and separate charges and transfers, Stripe debits refunds, the disputed amount, and the dispute fee from the platform. The platform then has to reverse the transfer to recover the seller's share. Verification matters too. An account with past-due requirements can lose the ability to take charges or receive payouts, when charges_enabled or payouts_enabled turns false. Each of those becomes a support ticket from a seller who wasn't paid.

Who does what

  1. Engineering runs a connected accounts webhook endpoint, handles account.updated, and records transfers and reversals per account.
  2. Operations watches verification requirements and contacts sellers before deadlines pass.
  3. Finance reconciles per connected account, covering charges in, fees kept, transfers out, and payouts sent.
  4. Support knows which charge type each payment used, because that decides who pays for a refund.

ChargeBell and Stripe Connect

ChargeBell isn't a tool for running a Connect platform, and it has no alerts for onboarding, verification, or transfers. It uses Stripe's OAuth connection itself. You approve read-only access on a Stripe screen, and from then on ChargeBell can read events but can't create charges, issue refunds, move funds, or change your account. On a platform that uses destination charges, the charges, refunds, and disputes happen on the platform account, so connecting that account brings them into Slack. The Stripe Slack integration page explains the setup.

Get alerted in Slack

Stripe events: account.updated, account.application.authorized, account.application.deauthorized, application_fee.created, transfer.created

ChargeBell posts Stripe events to the Slack channel you pick, written in plain English.

Related terms