Recurly Laravel Package

Product Decisions This Supports

• Monetization and pricing model — plan tiers, trials, coupons, add-ons, seat-based vs. usage-based pricing, grandfathering. A direct Recurly client lets you test pricing changes against real subscription data before committing them to the roadmap.
• Build vs. buy for billing — the strategic decision is Recurly (buy) versus Stripe Billing, Paddle, or an in-house ledger. This package is glue, not a differentiator; it only lowers the integration tax after Recurly is chosen. Do not let a library choice drive a vendor choice.
• Subscription lifecycle roadmap — upgrades/downgrades, proration, pause/resume, dunning and involuntary-churn recovery, cancellation flows, win-back campaigns. Each is a revenue-affecting product decision that maps to Recurly primitives, and each is gated on having a working API client.
• Revenue and retention instrumentation — MRR/ARR, churn cohorts, expansion vs. contraction, failed-payment recovery rate. Direct API access lets you pull raw subscription, invoice, and transaction objects into your own warehouse instead of depending on Recurly's dashboards.
• Self-serve vs. sales-assisted motion — whether checkout, plan changes, and payment-method updates can run through Recurly Hosted Pages or need custom UI. This determines how much of this client you touch at all.
• Market and tax scope — multi-currency, VAT/GST, localized payment methods, which decide which markets you can launch in.

When to Consider This Package

Consider it only if all of these hold:

• Recurly is already the committed billing vendor. The vendor decision precedes the library decision; this package cannot justify Recurly on its own.
• You are on PHP/Laravel and want server-side API access — not just hosted checkout — for plans, subscriptions, invoices, or webhook handling.
• You accept that this is an unvetted fork. Zero stars, zero dependents, no visible maintenance cadence. Treat it as source code you are adopting, not a dependency you are consuming, and confirm you have an engineer who can vendor and patch it.

Look elsewhere if any of these are true:

• You want the supported path. Recurly ships its own PHP client. The default should be the vendor SDK; a fork must justify itself with a documented, still-needed patch.
• You expect Laravel-native ergonomics. There is no evidence of a service provider, config publishing, facade, or queue-aware webhook handling. Cashier-style abstraction does not exist for Recurly — you will build the domain wrapper yourself.
• You are on Stripe or undecided. Stripe's Laravel ecosystem is dramatically deeper. Recurly wins on invoicing for sales-assisted B2B and dunning flexibility, not developer experience.
• Maintenance risk is unacceptable. Single-company fork, no downstream usage, no security policy. Bus factor and abandonment risk are yours.
• You only need checkout. Use Recurly Hosted Pages or their JS library and skip server-side integration almost entirely.

Recommendation: default to Recurly's official PHP client. Adopt this fork only with a named internal owner, a review date, and a documented reason it exists.

How to Pitch It (Stakeholders)

To executives: This is a low-level library for talking to Recurly, our subscription billing vendor. It is not a product decision in itself — the strategic question is whether Recurly remains our billing platform, and this only affects how cheaply engineering can wire it up. As presented, it is an unmaintained third-party fork with no adoption and no support channel. My recommendation is to use Recurly's official PHP SDK and treat this package as a reference implementation at most. The cost of the wrong call is measured in weeks of integration rework and billing-adjacent incident risk: avoidable, not existential.

To engineering: Treat moovly/recurly as unproven. Diff it against the official recurly/recurly-client-php, confirm which Recurly API version it pins, and identify whether the fork carries a patch we actually need or simply lags upstream. Assume we own everything around it: container binding and config, retry/timeout policy, idempotency on writes, webhook signature verification, queue-backed processing, and test fixtures. Estimate that overhead explicitly — it is the real cost of a "free" package. If we do adopt it, isolate it behind our own RecurlyClientInterface and BillingService so the implementation is swappable in one file, then vendor or fork it internally with a named owner and a review date.