Stripe Connect Integration

The difference is in where the charge is created. For an Express account the payment is made on BrightStar's Stripe account with the organizer set as the transfer destination, so the money is routed out as part of the same transaction. For a Standard account the payment is created directly on the organizer's own account instead. In both cases BrightStar's platform fee rides along on that one payment as an application fee, rather than being invoiced back afterwards, so there is no later reconciliation step between the two accounts.

Express accounts are created quietly in the background with card payment and transfer capabilities requested, and the connect step just hands you Stripe's own hosted onboarding to finish. Standard connects over OAuth instead, and the callback stores the account identifier Stripe returns along with a marker recording that it is a Standard account, which is what later decides how charges are built. The status shown afterwards is read back from Stripe rather than being a local flag, covering whether charges and payouts are enabled and whether the transfer capability has actually turned active.

The practical consequence of the two models is visibility. With Standard the charge lives on your own Stripe account, so payments appear in your Stripe dashboard directly and BrightStar's fee shows as an application fee against them. With Express the charge lives on the platform account and what lands on yours is the transfer. One thing applies to both: the transfers capability has to reach an active state before money can move, and an account can be created and even take a payment while that capability is still pending.

Payment intents are created with automatic payment methods switched on, which means Stripe decides what to offer based on the buyer, the currency and the region rather than BrightStar maintaining a fixed list. The wallet buttons come from a separate express checkout element, and it only renders when the device genuinely has a wallet available, so there is no empty grey bar when it does not. Apple Pay additionally requires the checkout domain to be registered with Stripe before the button will appear at all, and Google Pay needs a supporting browser with a card already saved.

None of that documentation passes through BrightStar. The account is created with little more than an email address and the capabilities being requested, and every identity, ownership and banking detail is entered on Stripe's own onboarding pages. What is stored on the BrightStar side is the account identifier, whether it is Express or Standard, and the current capability status read back from Stripe. That is deliberate: it keeps sensitive verification material inside Stripe's compliance boundary, and it is also why support here cannot look up or amend what you submitted.

While Stripe is still reviewing, the transfers capability sits in a pending state rather than active, and BrightStar re-reads that status from Stripe rather than caching a one-time result, so the connection page reflects the real position each time it is checked. A half-finished onboarding is resumable: a new onboarding link can be generated to pick up where it stopped, which matters because these links are short-lived and an old one will have expired. Until the capability turns active, payouts cannot move even if the account otherwise looks connected.