Is there a Laravel Cashier for Symfony? Every Stripe subscription bundle, checked in 2026

Short answer: there is no official Laravel Cashier for Symfony. Cashier is a first-party Laravel package; the Symfony ecosystem never shipped an equivalent. There is one young community port, a handful of Stripe wrappers, and a long tail of abandoned bundles written for Symfony 2.

Everything below was checked on Packagist and GitHub on September 24, 2026. Versions and dates are written down so you can re-check them. Disclosure before anything else: I sell ShipAnvil, a Symfony SaaS kit whose billing module is one of the options at the end. Read accordingly.

What "a Cashier" actually means

Strip the brand and Cashier is a precise promise. A developer searching for it wants:

• a billable model: $user->newSubscription('default', $price)->create();
• trials, plan swaps with proration, cancel at period end, resume during the grace period;
• Stripe Checkout and the customer portal, so you never build a card form;
• webhooks that keep a local copy of the subscription in sync, so your app can ask "is this customer subscribed?" without an API call;
• invoices you can list and download.

That list is the yardstick for every package below.

The shelf, checked on September 24, 2026

makfly/stripe-cashier-bundle: the only real Cashier port. Its README says it plainly: "Stripe billing for Symfony 7.x and 8.x, inspired by Laravel Cashier". The source tree follows Cashier's shape: a BillableTrait, a SubscriptionBuilder, Doctrine entities for customers, subscriptions and subscription items, coupons and promotion codes, tax rates, PDF invoices rendered through Dompdf or Snappy, a webhook endpoint with a store of processed events, and Messenger messages for the slow work. MIT licensed, PHP 8.2+, Stripe SDK ^16.0. The caveat is age: the repository was created in March 2026 and Packagist lists a single tagged release, v1.6.0 of July 18, 2026. If Cashier's API is what you miss, start here, and read the webhook handling before you trust it with revenue.

payum/payum-bundle: alive, but built for payments, not subscriptions. Payum is the serious, long-running payment abstraction of the Symfony world (Sylius builds on it), and the bundle is maintained: 2.7.2, released July 7, 2026, supports Symfony 5.4 through 8. The catch is the Stripe gateway itself: payum/stripe still requires stripe/stripe-php ^7.0 on its main branch, while the current stable SDK is 21.3.2 (September 9, 2026), and its subscription guide goes through the Plans API that Stripe has since superseded with Prices. Payum is a good answer to "take a payment through 35 gateways". It is not a subscription lifecycle.

herdwatch/stripe-bundle: an SDK wrapper, kept current. A maintained fork of the old Miracode bundle: v3.1.4 of July 22, 2026, PHP 8.3, Symfony 6.4 and 7 (not 8 yet), Stripe SDK 16.1 or later. It configures the SDK, turns incoming webhooks into Symfony events, and can mirror Stripe objects (customers, subscriptions, invoices…) into Doctrine entities you extend. Useful plumbing. What a subscription means for your app (states, grace periods, access) is still yours to write.

fpt/stripe-bundle: webhooks as Symfony events, and that's the scope. Clean and honest about it: the README lists "handle Stripe webhooks as Symfony events" as what it does today, with Doctrine sync and Messenger listed under "next steps". Last release 0.13, October 2024, Symfony 5.4 to 7.

The graveyard. flosch/stripe-bundle and serendipity_hq/stripe-bundle are marked abandoned on Packagist. avro/stripe-bundle, terox/subscription-bundle and simpleweb/saas-bundle target Symfony 2 to 4. They all still come back from a Packagist search for "stripe" or "subscription", so read the required Symfony version before anything else.

What no bundle decides for you

The honest finding of this survey: the SDK wrapping is the easy 10 %. Whatever you install, four decisions stay on your desk, and they are the ones that turn into support tickets.

1. Who is the customer? Cashier bills a user. Most B2B SaaS bill an organization: the subscription belongs to the team, survives the founder leaving, and every member inherits the plan. Retrofitting that after launch means migrating live subscriptions.
2. What happens when Stripe sends the same event twice, or out of order? It will. Your handler needs an inbox that deduplicates by event id, and a single place that decides whether a status transition is legal. The full pattern, with code, is in Stripe subscriptions in Symfony: the architecture that survives production.
3. Are you sure you want Stripe? Selling to consumers in fifty countries means VAT and sales tax in each of them. A merchant of record like Lemon Squeezy takes that on, for a larger fee. A Stripe-only bundle makes that choice for you and makes it expensive to undo; the trade-off is laid out in Lemon Squeezy vs Stripe for a Symfony SaaS.
4. How does a controller know what the plan allows? Checking $subscription->status === 'active' in forty places is how a "past due" customer keeps premium features for three months. Entitlements belong in one service, read by one attribute.

So which one?

• You want Cashier's API and you bill users, on Stripe only: try makfly/stripe-cashier-bundle, pin the version, and test the webhook paths yourself before launch.
• You need many payment gateways for one-off payments: Payum.
• You want to own every line and have two or three weeks: use stripe/stripe-php directly (or the herdwatch wrapper), and follow the inbox and single-write-path design linked above. It is not hard. It is just long, and the bugs only show up in production.
• You want the four decisions above already made and tested: that is the billing module of ShipAnvil.

ShipAnvil's billing module, precisely

ShipAnvil is not a bundle: it is a complete Symfony 7.4 application you start your SaaS from, so the billing code is plain application code that you own and can change. What it contains, as listed in its changelog:

• Stripe and Lemon Squeezy behind one PaymentProviderInterface, chosen by an environment variable, plus a fully local sandbox provider so dev and CI need no API key. Paddle is not included; it would be one more implementation of the same interface.
• Subscriptions belong to an organization, not to a user, with tenant-scoped queries enforced by a Doctrine filter.
• Hosted checkout, the provider's customer portal, cancel at period end and resume during the grace period, prorated plan changes, an invoice list.
• Signed webhooks go into an idempotent inbox and are processed asynchronously through Messenger; one write path normalizes both providers into the same seven subscription states and refuses illegal transitions.
• #[RequiresPlan] and #[RequiresFeature] on controllers, with Twig helpers, reading the same plan configuration as the pricing page.
• Functional tests that replay signed webhook fixtures for both providers, shipped with the code.

The live demo runs on the sandbox provider, so you can subscribe, upgrade and cancel without a card. Price and license terms are on the pricing page. If you are comparing whole kits rather than billing modules, the Symfony SaaS boilerplate comparison checks every living option the same way this page checked the bundles.