Stripe Connect

Read the Connect integration guide, the direct-charge guide for hosted Checkout, and the accounts v2 overview to decide who settles ticket funds. Direct charges on an Express connected account matched one seller per event, with a platform fee available later. Account links and account-update handling were implemented from those docs. No connected account was created on the service.

What worked

The direct-charge guide stated that the connected account is the merchant of record, which matched how ticket funds, fees, and disputes should settle.

What got in the way

Choosing among direct charges, destination charges, and the newer accounts API took several documents and depended on who should own the charge. Onboarding, settlement, and disputes were not observed on the live service.

Designed hosted Checkout with Connect Express-style accounts and destination charges, an application fee, and webhooks for completed, expired and refunded payments plus account updates. Worked from documented API behavior only; never ran against live or test mode.

What worked

Hosted Checkout fits a server-rendered app with no JS bundler and keeps PCI scope light. Destination charges plus application fees map directly onto a marketplace that has to split payments with sellers.

What got in the way

There are many details to keep in mind: the minimum session expiry, which needed a buffer for clock skew; Connect needing its own webhook endpoint and secret; refunds needing reverse transfer; and the account-type parameters changing across API versions.

Integrated Connect so organizers onboard through a Stripe-hosted account link and card payments use a destination charge to the connected account. Docs for destination charges, Express accounts, and the controller-properties migration were all required. The legacy account type is deprecated in this API version, and the replacement controller settings for dashboard access, fees, and charges were not obvious until the migration page and account type definitions were read together. No Connect account was created on the live service.

What worked

Destination charges match paying the organizer the ticket price while the platform creates Checkout. Hosted account links avoid a custom onboarding form. The migration guide does explain the controller properties that replace the deprecated account type.

What got in the way

Creating an Express-style account now requires assembling controller properties, and that mapping took several doc lookups plus the SDK types. Onboarding, charges-enabled status, and reversing a transfer after a late payment were not verified without platform keys.

Read hosted-onboarding and destination-charge documentation, then integrated seller onboarding, seller-directed payments, and configurable fees. Local tests covered seller isolation, but no real connected account was exercised.

What worked

Destination charges matched the one-seller-per-order model, and hosted onboarding provided a documented integration approach.

What got in the way

Refund recovery and transfer review required additional application logic and operating instructions. Live account eligibility and payout behavior were not validated.

Used direct-charge and account-configuration documentation to implement organizer onboarding and connected-account tracking. The design fit organizers receiving their own proceeds, but onboarding was not exercised with real accounts.

What worked

Hosted onboarding and organizer dashboard access provided a clear alternative to building identity-verification and payout interfaces.

What got in the way

Account controller settings and connected-account event routing needed careful integration. Local validation initially exposed an application error when handling an unrelated account event.

Implemented Express-style connected accounts for a multi-organizer ticketing API: onboarding links, status, dashboard login links, charges-enabled gating before publish, direct charges with an optional application fee, and Connect webhooks. Did not complete onboarding against Stripe. Current account-creation docs split across legacy type express, controller properties, and Accounts v2.

What worked

Connect matches per-organizer payouts better than platform-collected funds or competing marketplace options considered. Account Links, login links, and account.updated webhooks mapped cleanly onto organizer status flags.

What got in the way

Choosing the right Accounts API for Checkout on connected accounts required extra searching. Docs recommend Accounts v2 or v1 controller properties, while older Express examples still use type express, so the payload was not obvious from one guide.

Wired Express connected accounts and destination charges with an application fee so sellers receive funds and the platform takes a cut. Added onboarding links and account-update handling. No Express account was created or onboarded against Stripe, so payouts and KYC were not observed live.

What worked

Express destination charges matched a multi-seller catalog better than treating the platform as merchant of record. Account IDs, charges-enabled flags, fee basis points, and account-update webhooks were straightforward to model in app config and services.

What got in the way

Connect was never enabled on a real Stripe account in this environment. Onboarding URLs and charge routing were implemented and tested with stubs only, so Express KYC, account links, and actual seller payouts were not validated.

Implemented Connect Express so each seller onboards, destination charges send funds to that account, and listings stay unpurchasable until charges are enabled. Account updates and a dashboard login link were wired in. Onboarding and payouts were not run against a real Connect account.

What worked

Express accounts, destination charges, an optional platform fee in basis points, and a charges-enabled gate matched a multi-seller shop model better than collecting on one platform account.

What got in the way

Express onboarding, login links, and destination charges were only coded and stubbed. Country limits and the platform fee were configured in code, not proven with a live connected account.