- Is fpt/stripe-bundle a Laravel package?
- No. It is a Symfony bundle, and its value comes from Symfony's service container, configuration tree and autowiring, none of which exist in Laravel. The only piece that transfers to a Laravel application is the underlying stripe/stripe-php SDK it wraps. If you are on Laravel, treat this as a reference implementation rather than a dependency.
- Can I install fpt/stripe-bundle with Composer in a Laravel project?
- Composer will resolve it, but nothing will happen: Laravel does not register the bundle's extension, compiler passes or services, so no Stripe client gets wired up. You would end up reimplementing that plumbing yourself while still carrying an unused dependency in your lock file. Bind stripe/stripe-php as a singleton in a service provider instead.
- Which Laravel versions does this Stripe bundle support?
- None. There is no Laravel service provider, facade, publishable config or Laravel version constraint, because the package targets Symfony. Laravel 10 and 11 compatibility is not claimed anywhere and no release notes suggest it. For billing features in Laravel, look at Laravel Cashier or the official Stripe PHP SDK.
- What does fpt/stripe-bundle add on top of stripe/stripe-php?
- It registers a configured Stripe client as a container service, maps configuration keys to API credentials and webhook secrets, and adds helpers for payment intents and subscriptions plus webhook event routing. In Symfony that is genuine boilerplate removal, roughly a day or two of setup, but it is not an abstraction layer over Stripe. Subscription logic, proration, idempotency and invoice reconciliation stay with you either way.
- How do I configure Stripe API keys with fpt/stripe-bundle?
- Keys live in your Symfony configuration and are injected into the client service, so they stay out of application code and can be sourced from environment variables or a secret manager. In a Laravel app the equivalent is a config/services.php entry reading from env, with the client bound as a singleton. Either way, keep secrets out of source control and prefer restricted keys.
- Does the bundle verify Stripe webhook signatures and route events?
- The bundle advertises webhook handling with event routing, but the documentation is thin, so check the source to see whether signature verification is performed by the bundle or delegated to the Stripe SDK's Webhook::constructEvent. Verification is the part that actually matters and it is a small amount of code either way. In Laravel you would implement it in a controller behind a route excluded from CSRF checks.
- Does fpt/stripe-bundle pin stripe/stripe-php or let me set the Stripe API version?
- Verify this before adopting, because a wrapper can pin the SDK major version or obscure where the API version is configured. Stripe ships new API versions several times a year, and a mismatch between webhook payload shape and your object expectations is easy to miss. Confirm you control the api_version passed to the client and that the SDK constraint allows the version you need.
- Is fpt/stripe-bundle safe to use in production for payments?
- The dominant risk is sustainability rather than code quality: it is a single-maintainer package with around fourteen stars, no dependents and a release in late 2024, so you would be its most serious consumer. Payments failures are revenue-visible, which makes an unvalidated dependency in the payment path a hard sell. The MIT license means you can fork it, and wrapping it behind your own gateway interface keeps that exit cheap.
- How do I test Stripe payments if I use this bundle?
- Because the bundle is a thin layer, most meaningful tests target your own code: mock the injected client or your own gateway interface and assert your payment and subscription flows. Use Stripe test keys and test clocks for integration tests against the API, and make sure tests can never hit live keys. In Laravel the same approach applies with the SDK bound as a singleton you can swap in the container.
- What are the alternatives to fpt/stripe-bundle for a Laravel application?
- For Laravel, bind stripe/stripe-php as a singleton in a service provider, put configuration in config/services.php and call the SDK directly; you get the same ergonomics with no orphan dependency. If you need subscriptions, Laravel Cashier covers much of the billing surface out of the box. For Symfony projects the bundle is a reasonable, shallow convenience, but it is worth comparing against more established, maintained Stripe bundles.