Stripe Laravel Package

Product Decisions This Supports

• Build vs. buy on payments: this package lets you avoid building Stripe plumbing (intents, webhooks, refunds, payment-method storage) inside a Shopper-based storefront. The decision it informs is narrow but real: "do we spend sprints on payment glue, or adopt the framework's first-party integration?"
• Checkout and conversion roadmap: Stripe support is the gating dependency for card payments, saved payment methods, and (depending on the core implementation) wallet/SCA flows. It directly determines whether checkout can ship, so treat it as a launch blocker rather than a nice-to-have.
• Market and pricing experiments: once Stripe is wired in, you can run currency, promo, and subscription/trial experiments without re-architecting checkout. The package is a prerequisite for a subscription or recurring-revenue roadmap item.
• Operational scope: refunds, disputes, and webhook reconciliation are back-office features that this integration either enables or forces you to build by hand. That shapes support headcount and finance tooling decisions.
• Platform commitment: adopting this package is effectively a bet on the Shopper framework as your commerce layer. That is a bigger product decision than the package itself, and it should be made deliberately, not as a side effect of "we need Stripe."
• Buyer-facing use cases: single-store Laravel commerce, MVP/launch storefronts, internal or B2B ordering portals, and teams already standardized on Shopper who need card payments with minimal new surface area.

When to Consider This Package

Consider it when all of the following hold:

• You are already committed to shopperlabs/framework (or are seriously evaluating it) as your e-commerce core. This package is a component of that framework, not a standalone Stripe library.
• You want Stripe as your primary or only gateway and are comfortable with the framework's opinions on checkout, carts, and order models.
• You accept early-stage ecosystem risk: the framework's own component scores are low, the community is small, and you should expect to read the source rather than rely on documentation or Stack Overflow answers.
• Your team is Laravel-fluent and willing to extend or patch the integration in the parent monorepo when gaps appear.

Look elsewhere when:

• You are not on Shopper. There is no reason to adopt this; use stripe/stripe-php directly or laravel/cashier for subscriptions. This package's value is its framework integration, which is zero outside Shopper.
• You need multi-gateway abstraction (PayPal, Adyen, local methods alongside Stripe). Prefer a payment abstraction layer over a single-gateway integration.
• You need vendor support, SLAs, or a large hiring pool. Zero stars, zero dependents, and a read-only split signal a very thin ecosystem. Weigh that against your risk tolerance for a revenue-critical path.
• You need mature subscription billing. Cashier has years of hardening this integration likely does not.
• You need to file issues or PRs here. This repository is a read-only subtree split; contribution and issue tracking live in shopperlabs/framework. Adopt it knowing your change path is upstream.

Two engineering caveats to confirm before committing: pin the version explicitly, since split repositories can drift from the monorepo; and audit the webhook/signature-verification and idempotency handling yourself, because payment correctness cannot be assumed from a low-signal package.

How to Pitch It (Stakeholders)

For executives (one paragraph): The Shopper Stripe component is a pre-built payment integration for our Laravel e-commerce framework, intended to save us the engineering cost of wiring Stripe into checkout ourselves. The trade-off is ecosystem maturity: it is a small, early-stage open-source component with no measurable adoption, so we should treat it as "free head start, with maintenance risk" rather than a supported vendor product. Recommendation: adopt only if we are already standardizing on the Shopper framework; otherwise the same effort is better spent on Stripe's official SDK. Either way, budget for our own review of the payment and refund paths, since that is a revenue-critical surface.

For engineering (short version): This is a subtree split of Shopper Core — read-only, do not open PRs here; upstream changes go to shopperlabs/framework. It gives us Stripe payment handling inside Shopper's existing checkout abstractions, which is cheaper than hand-rolling but couples us to the framework's order and cart models. Before we depend on it, we need to verify webhook signature validation, idempotency, refund/dispute handling, and 3DS/SCA coverage, and we need to pin a version and track upstream releases. If we are not on Shopper, skip it and use stripe/stripe-php or Cashier.

Decision framing: Approve as a framework-aligned, low-commitment dependency with a documented exit path to direct Stripe SDK usage, not as a strategic platform bet. Gate adoption on a two-day technical spike that exercises checkout, refund, and webhook flows in staging.