- Is kj/payment-stripe-bundle a Laravel package?
- No. Despite being described as a Laravel/PHP integration, it is a Symfony bundle: it ships a Bundle class, a DependencyInjection extension, a YAML config tree, and container compiler passes. Laravel does not execute any of that, and there is no service provider, facade, or publishable config file. Treat it as reference material and naming precedent rather than a dependency you can install into a Laravel app.
- Can I install kj/payment-stripe-bundle in a Laravel 10 or 11 app with Composer?
- Almost certainly not cleanly. Composer will likely refuse dependency resolution because of Symfony component and Guzzle 7 conflicts on a modern stack, and if it does resolve it will drag an end-of-life stripe/stripe-php SDK into production. There is no current stack where installing this as-is is the right move.
- Which Laravel, PHP, and Symfony versions does it support?
- The package does not target Laravel at all, so there is no Laravel version support to speak of. Its composer constraints are likely pinned to PHP 5.x or 7.0-era requirements with legacy Symfony components. Check composer.json directly, but plan on the answer being too old for PHP 8.1+ and Laravel 10 or 11.
- How do I configure the Stripe API keys and environment?
- Configuration is done through the bundle's YAML config tree, which only loads inside a Symfony kernel. That pattern encourages committing API keys to version control, which you should never do. In a Laravel app you would instead use environment variables and a config file published by your own service provider.
- Does it support Payment Intents, SCA, and 3D Secure?
- The overview advertises payment intent creation and confirmation helpers, but the underlying SDK is likely pinned to the Charges-API era, before PaymentIntents and SCA existed. Confirm the pinned Stripe API version and whether any 3DS flow is actually implemented before relying on it. Without SCA support, card payments from the UK and EU will decline silently under PSD2 and show up in your dashboard as a conversion drop rather than an error.
- Does it verify Stripe webhook signatures?
- The README claims webhook signature verification and event dispatch, but the technical review flags signature checking as a gap to assume missing until you have read the source. Unverified webhooks are spoofable payment confirmations, which is both a revenue-recognition and a fraud exposure. Verify this in code, or implement verification yourself with the official SDK.
- Does it use idempotency keys to prevent duplicate charges?
- Assume not. Idempotency keys are listed among the likely gaps, and without them a network retry on a payment request can create a duplicate charge. That converts directly into refunds, support load, and chargeback fees, so implement idempotency in your own wrapper regardless of which SDK you use.
- Is kj/payment-stripe-bundle actively maintained and safe for production?
- The risk signals are poor: zero stars, zero dependents, and no visible maintainer of record. There is no confirmed test suite or license clarity from the listing, and a pinned legacy Stripe SDK carries its own security exposure. If you adopt it, budget every unknown as something your team will own indefinitely, including CVE response.
- What should I use instead for Stripe in Laravel?
- On a modern Laravel stack, use Laravel Cashier or a thin internal wrapper around stripe/stripe-php v13+. The bundle's only reusable asset is a handful of service classes, which is roughly one to three engineering days to reimplement cleanly against the official SDK. A single charge flow is days of work; subscriptions, refunds, disputes, and webhook reconciliation push into weeks either way.
- How do I migrate away from it if it is already in a legacy codebase?
- Use the strangler pattern. Define an internal PaymentGateway interface covering your domain operations, such as charge, refund, tokenize, and handleWebhook, and place it in front of existing call sites first so nothing else has to change. Then implement that interface on stripe/stripe-php v13+ and swap it in behind the scenes. The interface is the durable artifact: it keeps your provider choice reversible if the framework changes or a second gateway is added.