- Is scribe/stripe-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle. Its entire deliverable is a Symfony dependency-injection extension plus service definitions that register a configured Stripe PHP SDK client in a Symfony container. There is no Laravel service provider, facade, or config-publish tag, so none of that wiring transfers to a Laravel application.
- Can I use scribe/stripe-bundle in a Laravel application?
- Not without reimplementation. Loading the bundle would mean pulling Symfony's DI component into your Laravel app, which introduces a second container and a confusing class of resolution bugs. The practical option is to fork the service definition and rewrite it as a single Laravel service provider.
- How do I install and configure scribe/stripe-bundle?
- You install it with Composer as you would any Symfony bundle, enable it in your Symfony kernel, and set your Stripe keys under the bundle's configuration key. That procedure is Symfony-specific and does not map onto Laravel's package discovery or config publishing mechanisms. There is no artisan install or vendor:publish step.
- Does scribe/stripe-bundle support Laravel 11 or Laravel 12?
- There is no Laravel support at all, so Laravel version support is the wrong frame for this package. The bundle targets Symfony, and its PHP and Symfony constraints would need to be checked against your runtime before any use. For Laravel 11 or 12, use stripe/stripe-php directly with a small service provider.
- What does scribe/stripe-bundle give me beyond the Stripe PHP SDK?
- Effectively a configured Stripe client bound as a service, plus bundle-level config loading. In Laravel that is one service provider, one config array, and one env entry, which is roughly 20 to 40 lines you can write and own in under a day. The capability gap between this bundle and stripe/stripe-php is close to zero.
- Is scribe/stripe-bundle actively maintained?
- There are no meaningful maintenance signals: 0 stars and 0 dependents means no downstream production usage to surface bugs and no release cadence tracking Stripe API versions. For a payments integration path, that lack of pressure to stay current is a real risk. Assume you own any code you adopt.
- What license is scribe/stripe-bundle released under?
- GitHub reports NOASSERTION, meaning it could not identify a recognized SPDX license for the repository. For commercial payment code that is a legal gate rather than a footnote, and it blocks even copying the code as reference until clarified in writing with the maintainer.
- Will scribe/stripe-bundle constrain my Stripe PHP SDK version?
- Likely yes, and that is disqualifying on a payments path. A thin wrapper that pins or caps the SDK either blocks a security-relevant upgrade or breaks when you take one, and Stripe's SDK moves on a rolling cadence with pinned API versions and occasional major breaks. Confirm the SDK version range before relying on it in any capacity.
- What should Laravel developers use instead of scribe/stripe-bundle?
- Use stripe/stripe-php as a first-class Composer dependency and bind a configured StripeClient as a singleton inside a service provider. If your actual need is billing abstractions such as subscriptions, invoices, and payment methods, evaluate laravel/cashier instead. Both are maintained, licensed clearly, and designed for Laravel's container.
- Can I reuse scribe/stripe-bundle as reference code for my own Laravel service provider?
- Only after the license is clarified, since NOASSERTION means no identified terms to rely on. The only pattern worth copying is binding a configured StripeClient as a singleton, and that pattern is trivial to write from the Stripe PHP SDK documentation alone. There is no need to touch the bundle to get it.