- Is quartet/stripe-bundle a Laravel package?
- No. The TPM assessment identifies quartet/stripe-bundle as a Symfony 2 bundle that integrates through Symfony's dependency injection container and configuration tree. It has no Laravel service provider, facade, or config publishing convention, so Laravel developers should not treat it as a native Laravel Stripe integration.
- Can I install quartet/stripe-bundle in a Laravel application?
- Generally no. Its Symfony 2.x dependencies and era-appropriate Stripe PHP SDK conflict with modern Laravel/Illuminate components on PHP 8.1 and later, so Composer will fail or force dangerous downgrades. For Laravel, install stripe/stripe-php behind a service provider or use Laravel Cashier instead.
- Which Laravel versions does quartet/stripe-bundle support?
- None. It targets Symfony 2.3 through 2.8 and predates Laravel's modern package conventions such as service providers, facades, and publishable config. There is no Laravel version constraint or tested support matrix for Laravel 8, 9, 10, or 11.
- How do I configure Stripe API keys and webhook secrets with quartet/stripe-bundle?
- In its native Symfony 2 setup, configuration is loaded through the quartet_stripe configuration tree and Symfony's dependency injection container. It does not use Laravel's config/services.php, .env publishing, or config:cache conventions. In Laravel you should store keys in config/services.php and implement webhook secret verification with the current Stripe SDK.
- Does quartet/stripe-bundle support PaymentIntents, SCA, or 3D Secure?
- Not reliably. The bundle wraps an old stripe/stripe-php version that predates PaymentIntents, SCA/3DS2 flows, and modern idempotency-key propagation. Any current Stripe integration needs PaymentIntents and authentication handling, so these flows would have to be rebuilt with the official SDK.
- How does webhook handling work in quartet/stripe-bundle?
- It provides Symfony service wiring for processing Stripe events, but it relies on the old SDK and bundle conventions. It does not give Laravel route, controller, or middleware scaffolding, and its signature verification model is not a substitute for current Stripe webhook verification. In Laravel you should build a signed webhook endpoint with stripe/stripe-php and validate the Stripe-Signature header.
- Can I use quartet/stripe-bundle for subscriptions and recurring billing?
- It includes subscription and payment intent helpers for common billing flows, but they are built around the older Stripe API and Symfony 2 wiring. They do not reflect current Stripe subscription, SCA, or idempotency requirements. Laravel Cashier is the better fit for Laravel subscription billing, and stripe/stripe-php is the safer base for custom flows.
- Is quartet/stripe-bundle maintained and safe for production?
- It is effectively abandoned, with 0 stars, 0 dependents, and no maintenance trail or downstream validation. Payments code has high blast radius, especially webhook signature verification, API version drift, and security patching. Production use would mean owning a fork indefinitely with no upstream to merge from.
- How should I test a Stripe integration if I reuse or fork quartet/stripe-bundle?
- Test against Stripe test mode with parity tests for payments, subscriptions, and webhook replay before replacing any legacy flow. Put an internal PaymentGateway interface in front of the bundle so tests and new code do not depend on Symfony 2 wiring. Then run a strangler migration to the current stripe/stripe-php SDK and verify idempotency, retries, and signature validation.
- What are the best Laravel alternatives to quartet/stripe-bundle?
- Use stripe/stripe-php directly with a small Laravel service provider for payments and webhooks, or adopt Laravel Cashier when subscription and billing semantics fit. Both are maintained and support modern Stripe APIs, unlike this legacy Symfony 2 bundle. If you are on a legacy Symfony 2 app, isolate the bundle behind an internal interface and plan a strangler replacement.