- Is flapjacklabs/chargify-bundle a Laravel package?
- No. It is a Symfony bundle (FJLChargifyBundle), not a Laravel package. It bundles a thin Chargify API client with Symfony dependency injection wiring. In a Laravel application the DI wiring is dead weight, and only the client wrapper is reusable.
- Can I composer require flapjacklabs/chargify-bundle in a Laravel app?
- It is technically installable because Laravel already ships several Symfony components, but the bundle expects a Symfony Kernel and ContainerBuilder compile phase for its extension to run. Its services and parameters will not be registered automatically in Laravel. The practical path is to read the extension and translate its definitions into a Laravel service provider instead of relying on the bundle.
- How do I integrate this Chargify bundle with Laravel?
- Clone the repo, run a short spike, then vendor the client classes into app/Services/Chargify or a private package under your own namespace. Re-express the bundle's services.yml and extension parameters as a ChargifyServiceProvider, publish config/chargify.php with the site subdomain, API key, and environment, and bind the client as a singleton. Strip all Symfony DI, event dispatcher, and kernel coupling. Estimated effort is one to three days if the underlying client is clean.
- Does this package support the current Chargify or Maxio API?
- It almost certainly targets the legacy Chargify API era with *.chargify.com endpoints, and Chargify is now Maxio. Endpoint deprecation, auth model changes, and webhook payload evolution are unmanaged. Confirm the targeted API version and auth scheme before committing to anything.
- Is flapjacklabs/chargify-bundle maintained and safe for production?
- The repository has zero stars, zero dependents, and a single maintainer, with no visible security patching, PHP version roadmap, or issue triage. Taking it as a dependency effectively means owning a fork from day one. Treat it as a reference implementation to mine, not a production runtime dependency.
- What PHP and Symfony versions does chargify-bundle support?
- The declared support matrix is not stated in the available context and should be treated as unknown. It likely pins Guzzle and Symfony component majors that can conflict with a modern Laravel composer.json, which is a classic source of unresolvable dependency graphs. Check its composer.json and run a dry-run install before planning anything.
- Does this bundle handle Chargify webhooks, idempotency, and rate limits?
- Likely not beyond raw HTTP calls. The assessment specifically flags webhook signature verification, idempotency keys, and retry/backoff as items you must add yourself. If you adopt the client, harden it with Laravel middleware for signature verification, queued jobs for webhook handling, and backoff for rate limits.
- Which parts of FJLChargifyBundle are reusable in Laravel?
- The thin Chargify API client wrapper is the only reusable asset. The DependencyInjection extension and Resources/config/services.yml are Symfony-specific dead weight. The bundle overall is a reference implementation, not a dependency, and the client's resource methods can be adapted for subscriptions, customers, and related API interactions.
- Does flapjacklabs/chargify-bundle have tests I can trust?
- There is no external evidence of test coverage because the package has zero dependents. The context notes unknown test coverage and no proof the client behaves correctly against live API edge cases. Ask the maintainer whether tests run against a recorded or mocked Chargify API or only cover happy-path unit scenarios.
- What should I use instead of this Chargify bundle in Laravel billing?
- Build a private company/laravel-chargify package or app/Services/Chargify classes from the reusable client, wrapped in a ChargifyServiceProvider with config and a typed facade or constructor injection. Alternatively, write a thin client against the current Maxio API using Guzzle or Laravel's HTTP client. This avoids Symfony coupling and keeps PHP and dependency versions under your control.