Weave Code
Stripe Laravel Package
cartalyst/stripe
Cartalyst Stripe is a PHP/Laravel wrapper around the Stripe API, offering a fluent, object-oriented SDK for charges, customers, subscriptions, invoices, coupons, and webhooks. It streamlines payment integration with clean syntax and Laravel support.
Cartalyst Stripe is a Composer-installable PHP SDK that wraps the Stripe API in a clean, fluent interface, making it straightforward to manage customers, charges, subscriptions, and refunds. It ships with first-class Laravel integration while keeping a framework-agnostic core, so the same expressive syntax works in any PHP project.
- Laravel service provider and
Stripefacade for quick setup - Fluent resource methods for customers, charges, subscriptions, and refunds
- Configurable API keys and Stripe API version
- Framework-agnostic core usable outside Laravel
- PSR-compliant, dependency-light architecture
Frequently asked questions about Stripe
- How do I install cartalyst/stripe in a Laravel app?
- Run composer require cartalyst/stripe and let Laravel package discovery register the Cartalyst Stripe service provider and Stripe facade. Publish the package configuration with the vendor:publish Artisan command, then add your STRIPE_KEY and STRIPE_SECRET values to the .env file. Because the last release predates Laravel 9, confirm that discovery still registers the provider on your framework version before wiring it into a real project.
- Does cartalyst/stripe work with Laravel 9, 10, and 11?
- The most recent release is v2.4.6 from October 2021, which predates Laravel 9, so the package's illuminate constraints may not resolve cleanly on Laravel 9, 10, or 11. Verify installation in a throwaway branch using your exact PHP and Laravel versions before treating adoption as a decision. If the constraints conflict you will need a fork, a constraint override, or a migration to the official Stripe SDK. Nothing in the package guarantees support for newer framework releases.
- How do I use multiple Stripe accounts with cartalyst/stripe?
- Multi-account support is the package's strongest genuine differentiator. The published config defines a default profile plus a profiles array, and you switch profiles at the call site with something like Stripe::profile('eu')->customers()->create([...]). That lets you run regional entities, separate brands, or clean test and live separation from a single integration without forking it.
- Is cartalyst/stripe built on top of the official stripe/stripe-php SDK?
- No. It is a Guzzle-backed client with its own resource classes that map one-to-one onto Stripe endpoints and return plain PHP arrays rather than objects from the official SDK. Adopting it alongside stripe/stripe-php means two client stacks, two response shapes, and two exception hierarchies in the same codebase. Budget for that reconciliation if part of your application already uses the official SDK.
- How do I verify Stripe webhook signatures with cartalyst/stripe?
- There is no constructEvent equivalent, so webhook verification is DIY. Read the Stripe-Signature header, take its t and v1 values, sign the t.body payload with your endpoint secret using HMAC SHA-256, and compare in constant time before calling json_decode. Alternatively pull in stripe-php just for its signature verification helper. Also confirm that the event shapes you depend on existed before the package's 2021 API surface cap.
- Can I use cartalyst/stripe outside of Laravel?
- Yes. The core is framework-agnostic and the Laravel service provider and Stripe facade are optional add-ons. Outside Laravel you instantiate the client with your secret key and API version and call the same fluent resource methods such as customers(), charges(), and subscriptions(). You manage the client instance and configuration yourself rather than resolving a container singleton.
- Does cartalyst/stripe handle subscription proration, trials, and dunning?
- No. The package ships no billing logic: subscriptions are CRUD over Stripe's objects. There is no proration engine, dunning state machine, trial lifecycle, tax determination, usage rating, or invoicing workflow. If trials, plan changes, proration, tax, or entitlements are core to your product, that logic is your internal scope and a thin wrapper is likely the wrong tier.
- How should I configure the Stripe API version in cartalyst/stripe?
- Pin api_version explicitly in the published config rather than relying on your Stripe account default. Otherwise a dashboard-side version bump silently changes response shapes underneath you. Also confirm that the API version the package targets is still accepted by Stripe, since the client itself has not been updated since 2021.
- Is cartalyst/stripe still maintained and safe for production?
- Treat it as frozen: the last release was v2.4.6 on 2021-10-09, with roughly 278 GitHub stars, no dependents, and no published security-response commitment. Before production use, verify the locked Guzzle version is CVE-clean and that the full dependency set resolves against your PHP and Laravel versions. It is defensible for an incumbent integration with low switching urgency, but greenfield adoption of an unmaintained wrapper is a decision you will likely re-litigate within a year. Note also that refund semantics changed in 2.4.6, where refunds keyed off a charge versus a payment_intent use different call shapes.
- What are the alternatives to cartalyst/stripe for Laravel Stripe integration?
- The official stripe/stripe-php SDK is the primary alternative: it is actively maintained, includes webhook signature verification, and supports PaymentIntents, SetupIntents, and payment methods added after 2021. Laravel Cashier is the option when you want subscription billing logic rather than raw API plumbing. Staying on cartalyst/stripe mainly makes sense if you already depend on its fluent array-returning syntax or its multi-profile configuration.
Weaver
How can I help you explore Laravel packages today?