Laravel Cashier Stripe Connect Laravel Package

Technical Evaluation

What this package is: A thin extension of Laravel Cashier that adds Stripe Connect semantics to Cashier's billable models — destination charges, application fees, and platform-controlled transfers. The value proposition is not new Stripe capability (Stripe Connect is a mature, first-class Stripe product with an official SDK) but ergonomics: expressing marketplace splits through the Cashier API surface our engineers already know. That framing matters for the build-vs-buy call, because the underlying capability is available to us either way; what we would be buying is an abstraction and the maintenance of it.

Architecture fit: Reasonable, with one caveat. Because it extends Cashier rather than replacing it, it inherits Cashier's decisions — the Billable trait, cashier_customer_columns/subscriptions migrations, webhook controller conventions, and Cashier's Stripe SDK version pin. Fit is therefore contingent on our existing Cashier posture: if we already run Cashier for subscriptions, this is additive and low-friction; if we do not, adopting it means adopting Cashier's schema and billing model as a package deal. The second caveat is where marketplace state lives: a two-sided marketplace needs connected-account identity, onboarding/KYC status, fee configuration, and payout reconciliation. A package of this size almost certainly does not own that state for us — we will still own the account-to-seller mapping and any ledger of record. We should assume we own the data model and validate that assumption before designing around it.

Integration feasibility: Mechanically easy — Composer install, likely config publishing and a migration, possibly a trait on existing models. The real work is not the package; it is the Connect lifecycle around it: account creation, hosted onboarding and re-onboarding after requirement changes, capability checks before allowing a charge, webhook handling for account.updated and capability.updated, and reconciliation of fees and transfers. A TPM should size the feature, not the dependency, and treat the dependency as a minority of that estimate.

Technical risk:

• Compatibility ceiling (high). Last release is April 2022 with Laravel 9 support and no evidence of Laravel 10/11. If our framework roadmap points at anything past 9, this package is either unusable or frozen at an unsupported framework version. This is the single most material fact in the package metadata and should gate any adoption decision.
• Cashier version coupling (high). The package pins a Cashier range, and Cashier in turn pins a Stripe PHP SDK range. That is a three-way constraint chain where any one upgrade can deadlock the other two. Expect this to be the first thing that breaks during a framework upgrade.
• Stripe API drift (medium-high). Stripe deprecates API versions on a rolling basis. An unmaintained wrapper around charge creation with application fees and transfers will silently carry stale request shapes, and the failure surface is money movement, not a 500 page.
• Adoption and bus factor (medium-high). 62 stars and a single-release-history pattern indicate low external usage. Low adoption means few eyes on correctness bugs, and a small issue base that looks "quiet" but may simply be unused. Assume single-maintainer risk and plan for the possibility of forking.
• Money-correctness risk (high impact, low detectability). Fee configuration errors, refund/chargeback behavior on destination charges, and transfer reversal semantics are easy to get subtly wrong and hard to detect without reconciliation. This risk exists with or without the package, but a convenience wrapper can obscure where the money math actually happens.
• Unknown blast radius. No changelog detail beyond the Laravel 9 bump. We cannot infer test coverage, webhook handling completeness, or idempotency behavior from the metadata.

Key questions (answer before committing engineering time):

1. What Laravel and Cashier versions does the package currently constrain, and are those constraints additive or substitutive? Read composer.json directly.
2. Is there any signal — issue, branch, PR — of Laravel 10/11 support, and what is the maintainer's stated policy?
3. Does the package handle Connect webhooks (account.updated, capability changes, payout.*), or does everything except charge creation remain ours to build?
4. Which Connect charge model does it support — destination charges, separate charges and transfers, or both — and does that match our payout and refund requirements?
5. Where is the fee computed — client-side, config, or Stripe-side — and is there an auditable record of application fees per transaction?
6. What is our actual build cost for the same abstraction directly against stripe/stripe-php? If it is two to three weeks, this package's maintenance risk may not clear the bar.
7. Do we already run Cashier in production, and are we willing to inherit its schema and SDK pins?
8. Security and license posture: MIT is fine; check advisory history and whether the package is direct or transitive.

Integration Approach

Stack fit: Target Laravel 9 / PHP 8.x with Cashier already in the stack. If we are on Laravel 10+, assume this package is not an option until proven otherwise and plan the build-direct path instead. The decision rule for the TPM is: the framework roadmap is the input; the package is the constraint to solve — never let a marketplace feature pin the platform to an unsupported runtime.

Migration path:

1. Spike branch, not a feature branch. Install against a real Cashier model set in a throwaway environment. Publish config and migrations, exercise charge creation against Stripe test mode with a connected test account. Goal is to learn the actual API surface, not to ship.
2. Verify the constraint chain explicitly. composer why-not against laravel/framework, laravel/cashier, and stripe/stripe-php. Record the resolved versions; that triplet is the maintenance contract we are accepting.
3. Model the state we must own. Draft the schema for connected accounts, onboarding status, fee policy, and a transaction/ledger table. If the package's migration conflicts with this, that is a design signal, not an inconvenience.
4. Build the Connect lifecycle ourselves and treat the package as a charge helper only: account creation, onboarding links, capability gating, webhook ingestion, reconciliation job.
5. Reconcile against the Stripe API, not against our own DB. A nightly job that compares our ledger to Stripe balance transactions and transfers is the acceptance test, not a nice-to-have.
6. Pilot with a single connected account and a small dollar volume before opening onboarding to all sellers.

Compatibility: The critical check is the full dependency graph, not a green install. Pin Cashier and the Stripe SDK explicitly in composer.json rather than floating ranges — the three-way constraint is where this breaks. Pin the Stripe API version on the account and document it. Test webhook signature verification and idempotency in staging; Stripe retries, and duplicate transfer logic is a real money bug.

Sequencing: (a) Constraint audit and build-vs-buy sizing — two to three days, no code merged. (b) Spike against Stripe test mode — one week. (c) Decision gate: adopt package vs build direct against the Stripe SDK. (d) Feature build with the package as a helper — several weeks, dominated by onboarding and reconciliation, not by the package. (e) Staging soak with a test connected account and replayed webhooks. (f) Production pilot, one seller, feature-flagged. Keep the package bump and any framework upgrade in separate changes so failures are attributable.

Operational Impact

Maintenance: The dominant recurring cost is that this package is effectively unmaintained relative to the framework cadence. That creates a standing tax: every Laravel or Cashier upgrade starts with a blocked-on-vendor investigation, and the likely end state is forking the package or inlining its charge logic into our codebase. Budget for that outcome rather than treating it as an exception. Set an explicit abandonment threshold — for example, no release within one framework major cycle, or a Cashier constraint that blocks a planned upgrade — and pre-authorize the fork-or-replace decision trigger so it is not argued mid-sprint. Pin versions; never float this dependency.

Support: Community OSS, MIT, no SLA, no escalation path, likely one maintainer. Stripe's own support covers the Connect platform APIs but not our wrapper, so any incident debugs against a two-layer gap. Assign a named engineer as de facto owner for the marketplace money path — this is one of the few areas where ownership is non-optional — and document the fallback in the runbook: which module contains the fee logic, how to bypass the package, and how to reconcile a discrepancy manually. If we are a payments-adjacent business, a second reviewer on any change touching fee computation or transfer creation is a reasonable standing control.

Scaling: The package itself introduces no scaling characteristics. What scales is the Stripe integration: API rate limits, webhook volume (account and capability updates across many sellers), and the reconciliation job's runtime as transaction history grows. Design webhook handling to be queued and idempotent from day one — retrofitting idempotency after a duplicate transfer is an expensive audit. Fee configuration should be data-driven per seller, not hardcoded, because marketplace fee changes are a commercial decision that should not require a deploy.

Failure modes:

• Silent fee misconfiguration — margin leakage or overcharging sellers, discovered only at reconciliation or by a seller complaint. Mitigate with explicit fee tests and a daily reconciliation delta alert.
• Blocked framework upgrade — the package constrains Laravel/Cashier and stalls an unrelated roadmap item. Mitigate by never letting it sit on a critical path without the fork-or-replace threshold pre-authorized.
• Connected-account capability gaps — charges attempted against accounts that lost a capability or have incomplete requirements, producing failed payouts and seller support load. Mitigate by gating checkout on live capability state from the API, not cached onboarding flags.
• Webhook loss or duplication — stale account status or double transfers. Mitigate with signature verification, idempotency keys, and a replay-safe handler.
• Refund and chargeback semantics — destination-charge refunds, transfer reversals, and negative platform balances are the classic Connect footgun. These need product-level policy decisions, not engineering workarounds, and should be specified before launch.
• Abandonment / unpatched dependency — slow-onset; mitigated by the standing health check and having an in-house owner who can fork.

Ramp-up: Roughly one week of engineering to audit constraints, spike the package against Stripe test mode, and produce the build-vs-buy recommendation. The feature itself is larger, with onboarding and reconciliation consuming most of the effort. The TPM recommendation at the current information state is: treat this package as a candidate charge helper, not as a marketplace billing foundation. Run the constraint audit and the build-direct comparison in parallel, and gate adoption on whether the package survives the first dependency upgrade cleanly. If our framework roadmap goes past Laravel 9, the honest answer is that this dependency is already a write-off and the marketplace should be built directly against the Stripe SDK.