- How do I install moovly/recurly in a Laravel application?
- Install it with Composer using composer require moovly/recurly, then check the package's composer.json for any auto-discovered service provider and facade aliases. If the package ships a publishable config file, run php artisan vendor:publish to copy it into config/ so you can adjust credentials per environment. Because the package is a vendor-namespaced fork of Recurly's PHP client, verify the install actually registers the bindings you expect before writing billing code against it. Keep the lock file committed so the exact fork snapshot is reproducible across environments.
- Which Laravel and PHP versions does moovly/recurly support?
- The package page does not publish a supported version matrix, so treat PHP and Laravel compatibility as an open question. Inspect the require and require-dev blocks in its composer.json to see which PHP constraint, Laravel major, and Guzzle major it pins. Confirm it installs cleanly against PHP 8.2 and 8.3 on your target Laravel release, since a stale Guzzle or PHP constraint will block platform upgrades later. If the constraints are narrow or outdated, prefer the upstream Recurly SDK instead of patching a fork.
- Is moovly/recurly the same as the official recurly/recurly-client package?
- It is best understood as a vendor-namespaced repackaging or fork of Recurly's official PHP client, not a Laravel billing abstraction like Cashier. Before adopting it, diff it against a specific upstream tag to see whether it carries a patch, an API version pin, or simply a namespace change. If there is no documented reason for the fork, use recurly/recurly-client directly and put your own Laravel glue on top. A fork of a payment SDK only pays off when it fixes something upstream refused or has not shipped.
- How do I configure my Recurly API key and subdomain with this package?
- Configure the Recurly API key and the account subdomain through the package's published config file, populated from environment variables rather than committed values. Use separate Recurly sandbox and production subdomains and keys per environment so staging never touches live billing data. Cache the config with php artisan config:cache after deployment and confirm the package reads settings at runtime rather than at bootstrap. Never log the API key, and restrict access to the config file and .env on production hosts.
- Does moovly/recurly handle Recurly webhooks and signature verification?
- The package advertises Recurly webhook handling for billing events, but you must confirm it verifies the Recurly signature header before trusting any payload. Check that the verification logic matches the upstream client, since a divergent implementation is a security issue rather than a test failure. In practice you should still own a thin webhook controller that validates the signature, stores the event idempotently, and dispatches a queued job. Never perform subscription state changes synchronously inside the webhook request.
- Can I manage Recurly accounts, plans, subscriptions, and invoices with this package?
- Yes, the package exposes the underlying Recurly client's account, plan, subscription, and invoice operations, so anything the official PHP SDK can do should be reachable. There is no Laravel domain layer on top, so you still decide how those calls map to your own models and business rules. Wrap the calls in a BillingService or repository rather than calling them from controllers. That keeps plan changes, proration, and invoice retrieval logic testable and consistent across your app.
- Is moovly/recurly safe to use in production for subscription billing?
- It carries supply-chain risk: a zero-star, single-maintainer fork sitting directly in the payment path, with no security policy or audit trail. Before production use, confirm the MIT license is preserved, the code contains no incompatible additions, and the Recurly API version it pins is one you can live with. Treat it as adopting source code rather than consuming a maintained dependency, and budget a short audit rather than assuming it is drop-in. The safer default is Recurly's official client plus your own thin Laravel adapter.
- Is moovly/recurly actively maintained, and are its releases tagged?
- There is no evidence of active maintenance: no visible adoption, no dependents, and no published changelog that would signal regular releases. That matters because PHP 8.x deprecations, Guzzle major bumps, and Recurly API version changes will not be absorbed for you. Check the repository for tagged semver releases, recent commits, and a named owner before committing to it. If the fork is effectively a dead snapshot, pin it deliberately or fork it internally with an owner assigned.
- How do I test Recurly billing code without hitting the live Recurly API?
- Because the package is a thin SDK wrapper, the practical approach is to hide it behind your own interface and fake that interface in tests. Unit test your BillingService and webhook consumer against stub responses instead of calling Recurly over HTTP. For integration coverage, use a Recurly sandbox subdomain, not production, and reset test accounts between runs. Avoid mocking the vendor client class directly inside business logic, since that couples your tests to the fork's internals.
- How do I keep my Laravel code swappable between moovly/recurly and the upstream Recurly SDK?
- Put a RecurlyClientInterface adapter in front of the package and let a BillingService expose the domain operations your app actually needs. Nothing outside that adapter should import package classes, so replacing the supplier becomes a one-file change. Bind the adapter in a service provider and resolve it through the container or a facade of your own. This decouples roadmap delivery from the audit outcome and makes the vendor decision reversible at low cost.