- How do I install cheddar-getter/client in a Laravel application?
- Install it with Composer using composer require cheddar-getter/client. Because it is not a Laravel package, there is no auto-discovered service provider, facade, or publishable config file. You will need to bind it yourself, typically as a singleton in a dedicated service provider, with credentials pulled from config/services.php and environment secrets.
- Is cheddar-getter/client a Laravel package with a service provider and facade?
- No. It is a thin PHP HTTP wrapper around the CheddarGetter REST API and carries no framework opinions. It has no service provider, facade, config publishing, or contract binding, and it does not couple to Eloquent or any ORM. In Laravel you should treat it as a low-level SDK that sits behind an adapter you own.
- Which PHP and Laravel versions does cheddar-getter/client support?
- The last tagged release dates to October 2020, so official support for modern PHP and Laravel versions is unverified. Expect deprecation notices, missing type declarations, and possible fatal errors on PHP 8.2 and above. Run a short composer require spike against your actual PHP and Laravel matrix before committing to it.
- Will cheddar-getter/client conflict with the Guzzle version in my Laravel app?
- That is the main dependency risk. A 2020-vintage release likely pins an older Guzzle constraint, or it may bundle raw cURL, and either can collide with the Guzzle version shipped by current Laravel releases. A 30-minute Composer spike against your real dependency set will tell you whether the constraint resolves cleanly. If it does not, forking under the MIT license is straightforward but should be scoped as your maintenance work.
- How should I integrate CheddarGetter billing into a Laravel codebase?
- Define a BillingGateway interface and wrap the SDK in an adapter that implements it, keeping every vendor type inside that namespace. Bind the client as a singleton in a dedicated service provider, source credentials from config/services.php and environment secrets, and never reference the SDK directly from controllers, models, or jobs. Application code should see your DTOs rather than the SDK's arrays or objects, and an architecture test can enforce the boundary.
- Does this client handle retries, timeouts, and 429 rate-limit responses?
- Do not expect built-in retry or backoff logic, and there is no PSR-18 abstraction you can swap or decorate. Error handling is likely coarse, with limited exception types and no PSR-3 logging hooks, so 429s, timeouts, and 5xx responses may be surfaced inconsistently. You should add your own retry policy, timeout configuration, and structured logging around the adapter. Verify the actual behavior of the version you install with a small integration test.
- Does cheddar-getter/client support idempotency keys for charge creation?
- There is no built-in idempotency-key plumbing for charges or subscription creation in the client. Because this is revenue-affecting code, you must synthesize and persist your own idempotency keys and guard against duplicate submissions at the adapter layer. That usually means recording intent before the API call and reconciling after a timeout or ambiguous failure.
- How do I test Laravel code that depends on the CheddarGetter client?
- Keep the SDK behind your BillingGateway contract so tests can substitute a fake adapter and never hit the network. Write contract tests around the adapter itself, using recorded HTTP fixtures or a mock HTTP client, to confirm request shapes and error mapping. Architecture tests can also assert that no class outside the integration namespace imports vendor types.
- Does the client verify CheddarGetter webhooks or protect against replays?
- Webhook verification and replay protection are not features of this thin REST wrapper, so plan to implement them yourself. You will need to validate the signature or shared secret according to CheddarGetter's documentation, reject stale timestamps, and deduplicate event IDs. Also ensure webhook handlers call your own services rather than the SDK directly.
- Is cheddar-getter/client still maintained, or should I write my own client?
- The project has had roughly five years without a release, a single-maintainer history, around 28 stars, and zero dependents, so assume no security response path or issue-triage cadence. It is MIT licensed, which makes forking viable, but every fix and PHP compatibility patch becomes your responsibility. Weigh that against a hand-rolled client of roughly 400 to 600 lines against the documented REST API. For a high-blast-radius billing integration, either fork deliberately or build your own behind the gateway interface.