Subscriptions Laravel Package

Product Decisions This Supports

• Monetization strategy for an existing Flarum community. This extension is the lever for turning a free forum into a paid/membership community: recurring plans, subscriber-only access, and group-based entitlements mapped onto Flarum's existing permission model. The PM decision it informs is "can we monetize in-platform rather than migrate to Circle/Discourse/Skool?"
• Build vs. buy for billing. Adopting this defers building subscription state, plan-to-group mapping, and renewal/cancellation handling in-house. It does not replace a billing system of record — treat it as the entitlement layer, not the ledger.
• Roadmap sequencing for community features. If paid tiers are on the roadmap, gating (premium categories, badges, download access) becomes a dependency for content and moderation roadmap items; knowing the extension's plan/group model early shapes how you design categories and user groups now.
• Tier and packaging design. Subscription plans force explicit decisions on tier count, upgrade/downgrade paths, trial behavior, and what is gated vs. free — decisions that are cheap to make before launch and expensive after.
• Platform consolidation vs. point solution. Supports a "keep the community where it is, add revenue on top" bet instead of a re-platforming project. That is a materially different cost and risk profile for the roadmap.
• Adoption risk assessment as a decision input. 13 stars, a read-only subtree split, and a low composite score are themselves a signal: this is a low-visibility dependency. The PM decision is whether monetization can tolerate a thin-maintenance component, or whether revenue-critical billing justifies an owned implementation.

When to Consider This Package

Consider it when:

• You are already running Flarum and paid membership is a feature of the community, not the core product.
• Your entitlement model is simple: plan → user group → permissions. Flarum's group system is the natural place for this, and an extension that plugs into it avoids parallel auth logic.
• You want recurring-revenue capability without standing up a separate membership service, SSO bridge, or second user database.
• You can pin a version, own the upgrade testing, and accept community-grade support.
• You need the canonical behavior of the upstream extension and are consuming this split only as a Composer dependency — not as a place to file issues or PRs.

Look elsewhere when:

• You are not on Flarum — nothing here transfers to a generic Laravel app; you would be adopting a forum platform to get a billing feature.
• You need tax/VAT handling, invoicing, dunning, multi-currency, proration at scale, or revenue recognition. Use Stripe Billing, Paddle, or Chargebee as the system of record and let the extension own entitlements only.
• You require an SLA, security review, or vendor accountability. Low star count plus a read-only mirror means upstream is your real dependency and its maintainer bandwidth is your risk.
• Your access rules are complex (usage-based metering, per-seat, entitlements spanning multiple products) — the plan/group model will fight you.
• You are pre-product-market-fit and a free community is sufficient; monetization infrastructure added early is pure carrying cost.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a Flarum extension that lets us charge for community membership using the permission and user-group system we already run, so we can test a paid tier without re-platforming or building a billing stack from scratch. It converts an existing cost center into a possible revenue line at low incremental engineering cost. The trade-off is dependency risk: the project is small and community-maintained, so I'd position this as a fast, reversible experiment — keep billing with an established provider, keep an exit path to an owned entitlement layer, and don't let it become a single point of failure for revenue.

To engineering (one paragraph): It's a PHP Flarum extension following standard extension conventions — service provider registration, migrations for plan/subscription state, listeners for subscription lifecycle, and group assignment on subscribe/cancel. The surface area is modest and the integration points are the parts we already control (groups, permissions, categories). Two asks: pin the version and consume releases from the upstream monorepo rather than this read-only split, and write integration tests around subscribe/renew/cancel group transitions, since that's where a silent failure turns into either lost revenue or free access.

To finance/ops: It does not replace a payments system of record. Plan accordingly — recurring charges, refunds, and tax stay with the payment provider; this component decides who gets access.