Laravel Stripe Connect Laravel Package

Product Decisions This Supports

• Marketplace / multi-party payments feasibility. If your roadmap includes paying sellers, creators, contractors, or franchises, this package lets you validate Stripe Connect onboarding in days rather than committing a squad to a discovery phase. It answers "can we get a connected account linked to a user and gated on onboarding status?" before you've spent budget on the full money-movement stack.
• Build vs. buy for the onboarding slice. The OAuth connect flow — redirect, callback, token/account storage, redirect-back-to-app — is undifferentiated plumbing that every Connect platform rewrites. This repo is a concrete, readable baseline you can price against: roughly 300–500 lines of custom controllers versus a half-day spike using the package.
• Roadmap sequencing for monetization. It draws a clean line around phase one (account linking and identity handshake) and exposes what phase two actually costs: webhook handling for account.updated, capability/requirement state, payouts, refunds, disputes, and reconciliation. That gap is the real estimate, and seeing it early changes how you sequence the launch.
• Data model decisions. The package's storage of connected account identifiers against your User model is a forcing function for a question PMs own: is a connected account one-per-user, one-per-team, or many-per-org? Getting that wrong is a migration you pay for twice.
• Use-case triage. Marketplaces, gig platforms, creator monetization, donation splits, and SaaS platform fees all share this onboarding shape. A shared reference implementation tells you whether these are one feature or five.
• Effort and staffing signal. A working end-to-end connect flow in a spike gives you a credible burn-rate number for the "payments" epic instead of a T-shirt size.

When to Consider This Package

Consider it when:

• You're on a legacy Laravel 5.x codebase whose PHP and framework constraints already match the package's (last release January 2018), and the work has a short, known shelf life.
• You need a throwaway prototype or internal demo to test onboarding UX with real Stripe test-mode accounts, or to unblock a stakeholder conversation about marketplace economics.
• You want a reference implementation to read and copy, not a dependency to install — the routes/controllers/config pattern is the deliverable, and you plan to reimplement it against the current Stripe SDK.
• You need a rough size-of-effort estimate for the connect flow, cheaply, before writing an RFC.

Look elsewhere when:

• You intend to ship it. The repository is archived with no commits since 2018: no security patches, no compatibility with Laravel 8/9/10/11, no PHP 8 support, and no maintainer to escalate to. That's unowned risk in a path that touches money and identity.
• You need compliance-grade Connect. Stripe's Connect surface has moved substantially — Express and Custom accounts, Account Links for hosted onboarding, requirement collection and requirements.currently_due, capability gating, and Connect webhooks are now table stakes. This package predates and does not model any of it.
• Your flow needs webhooks. There is no handling for account.updated, capability changes, payout failures, disputes, or deauthorization. Without those, your UI will tell sellers they're "connected" while Stripe has flagged them for verification — the exact failure mode that generates support tickets and payout complaints.
• Your account model is anything but one-account-per-user, or your platform needs platform-controlled onboarding rather than OAuth redirect.
• You need ongoing Stripe API version management. Any maintained implementation — a fresh ~200-line controller set on the official stripe/stripe-php SDK, or Laravel Cashier where subscription billing overlaps — is a better production bet than resurrecting archived code.

How to Pitch It (Stakeholders)

To executives: This is a low-cost way to de-risk a monetization decision, not a technology bet. For a few days of one engineer's time, we can stand up a working Stripe Connect onboarding flow and answer the questions that actually gate the marketplace roadmap: how long does seller onboarding take, what does the seller see, and how much of the "payments" epic is generic plumbing versus our own product logic. The caveat is explicit — the package is archived and dated, so it is a prototype and a spec, never a production dependency. Production will require a rebuild against current Stripe APIs, and the spike's main output is a better estimate for that rebuild, including the webhook and compliance work the package doesn't cover.

To engineering: Treat this as a reference implementation, not a dependency. Read the routes, controller, and config to see the OAuth handshake shape and the account-storage pattern, then reimplement on the current SDK with Express accounts, Account Links, and a Connect webhook endpoint handling account.updated and capability changes. Expect one to two sprints for production-grade, most of it in state management and reconciliation rather than the redirect itself.

To design and support: The spike gives us a realistic onboarding prototype to test, and it surfaces the states we have to design for — pending verification, requirements due, restricted, deauthorized — that a naive "connected / not connected" toggle hides.