Stripe Laravel Package

Product Decisions This Supports

• Build vs. buy on Stripe plumbing. This package answers a narrow question: do we write and maintain the Laravel-to-Stripe glue ourselves, or adopt a wrapper that already handles API calls, configuration, facades, and Laravel service-provider wiring? Treat it as integration plumbing, not a billing platform. It ships no subscription state machine, proration engine, dunning, invoicing workflow, tax calculation, revenue recognition, or usage rating.
• Choosing the right abstraction tier for monetization. Three viable tiers exist: raw stripe/stripe-php, a thin Laravel wrapper like this package, or an opinionated billing layer such as Laravel Cashier or a merchant-of-record like Paddle/Lemon Squeezy. This package sits in the middle. The PM decision is which tier matches team size and how differentiated billing really is. If usage-based pricing, entitlements, tax, or multi-entity invoicing are core, a thin wrapper is the wrong tier.
• Roadmap confidence for pricing and packaging changes. A fluent resource API over customers, charges, subscriptions, invoices, and refunds can turn plan changes, trials, one-off purchases, and refunds into days of integration rather than a multi-sprint project. That improves how credibly product can commit to a packaging change within a quarter.
• Multi-account and multi-key configuration as a product enabler. First-class support for multiple Stripe accounts and keys unlocks regional entities, separate brands, marketplace-style splits, and clean test/live separation without forking the integration. Validate this against the go-to-market structure before committing.
• Geographic expansion gate. EU/UK launches require SCA/3DS-compliant flows, which means PaymentIntents rather than legacy Charges. The v2.4.6 refunds-with-PaymentIntents update is the relevant signal — and also the last release signal, dated October 2021.
• Vendor risk and total cost of ownership. 278 stars, zero dependents, and no release since 2021 are the most product-relevant facts. For greenfield work this reads “effectively unmaintained”; for an incumbent it reads “low switching urgency, but start budgeting the migration.”
• Technical-debt triage framing. If engineering flags this dependency, the correct product framing is that it is a contained, replaceable adapter over a well-documented public API. That makes it a bounded, schedulable backlog item with a named owner — not an emergency and not a re-architecture.

When to Consider This Package

Consider adopting when:

• You already depend on it in a running Laravel/PHP codebase and the migration cost clearly exceeds the benefit of switching now.
• You want a lightweight, expressive wrapper with a service provider, Stripe facade, and publishable config — and you explicitly do not want Cashier’s opinionated billing models or database schema.
• Your needs are simple and Stripe-only: customers, charges, basic subscriptions, refunds, and invoices, with no tax, revenue recognition, or metered/usage rating.
• You need multiple Stripe accounts or keys configured side by side and would otherwise build that configuration layer yourself.
• The surface you depend on is stable and covered by your own contract tests against Stripe test mode, so upstream stagnation is manageable rather than existential.

Look elsewhere when:

• You are starting something new. The official stripe-php SDK is the maintained default; Laravel Cashier is the maintained opinionated layer. Picking an unmaintained wrapper for greenfield work is a decision you will re-litigate within a year.
• You need Stripe capabilities introduced after 2021 — newer payment method types, evolving PaymentIntent/SetupIntent flows, current webhook event shapes, or modern API-version pinning.
• Your processor is not Stripe, or you want a merchant-of-record to absorb global tax and compliance.
• You need tax calculation, revenue recognition, usage rating, or a billing ledger — that is a billing-platform problem, not a wrapper problem.
• You run a marketplace with complex Connect split payouts, destinations, or application fees; you will end up on the raw SDK anyway.
• You require vendor support, a security-response commitment, or an SLA. Zero dependents and a release three-plus years old is not a support story.
• You are not on PHP/Laravel, or billing is owned by a dedicated service where a PHP wrapper adds no leverage.

Adoption criteria to verify before committing: Composer resolves against your PHP/Laravel version; the locked Guzzle dependency is not CVE-flagged; the package’s targeted Stripe API version is still accepted; webhook signature verification is implemented separately; and a migration path to stripe/stripe-php or Cashier is named.

How to Pitch It (Stakeholders)

For executives. This is a small, free (BSD-3), open-source PHP adapter that lets Laravel services talk to Stripe without us writing and maintaining that glue ourselves. It covers the fundamentals behind our revenue model — subscriptions, plan changes, invoices, refunds — and its multi-account configuration is useful if we operate under more than one Stripe account. The important caveat: it has not been updated since October 2021, has minimal community traction, and is not a billing platform. It does not provide tax, revenue recognition, dunning, proration, or usage rating. Adopt it as a contained integration layer with a named owner and a migration budget, not as a strategic billing dependency.

For engineering. Treat this as a thin wrapper over Stripe’s REST API, not as the official SDK. Responses are plain arrays, not \Stripe\* objects. Put a BillingGateway interface in front of it on day one, never call the facade directly from controllers or models, pin api_version explicitly, handle the package’s own exceptions, pass idempotency keys on every mutating call, verify webhook signatures outside the package, and store Stripe IDs rather than payloads. Contract-test the boundary against Stripe test mode and keep a clean swap path to stripe/stripe-php or Cashier.

For product and finance. This package can accelerate pricing, packaging, and refund workflows, but it does not solve billing operations. Validate multi-entity, tax, and geographic requirements before relying on it. If those are core, choose a higher-tier billing platform or the official SDK with an explicit billing service — and frame this package as a bounded technical-debt item, not a long-term platform bet.