Product Decisions This Supports
- Build vs. buy for billing. Subscription billing (plans, trials, proration, dunning, tax, invoicing, PCI scope) is a classic "don't build it" domain. This package is the integration cost line for the buy side of that decision — it tells you what a CheddarGetter-based implementation costs in PHP/Laravel terms versus rolling your own ledger or adopting Stripe Billing/Chargebee/Paddle.
- Billing provider selection. Adding this as a candidate gives the roadmap a third option beyond "Stripe Billing" and "build internal." Useful when you want a vendor with a lighter-weight API surface and lower fees than enterprise-tier competitors, and when your recurring-revenue model is simple enough that a full revenue platform is overkill.
- Estimating time-to-first-invoice. Because it is a thin, official API wrapper, it lets you scope an MVP subscription flow (create customer → assign plan → handle transaction outcomes) in days rather than a quarter. That estimate is what feeds the "can we launch paid tiers this quarter?" roadmap question.
- Legacy or acquired-codebase triage. For a team inheriting a Laravel app already on CheddarGetter, this package answers the migration question: keep the client, harden it, or re-platform. That's an ADR-level decision, not just a dependency bump.
- Feature scope for subscription lifecycle. Trials, plan changes, one-time add-ons, refunds, and cancellation flows all become "does the vendor's API express this?" questions. Mapping your product's billing requirements against the client's method surface is a cheap way to find scope gaps before committing.
- Opportunity signal. A high opportunity score alongside near-zero adoption and a 2020 last release suggests a genuine gap: a modern, Laravel-native subscription integration. That's a make-vs-fork-vs-contribute decision, and potentially a reason to maintain a thin internal adapter rather than depend directly.
When to Consider This Package
Consider it when:
- You have already selected CheddarGetter as the billing system. This is a vendor SDK, not a billing platform. It only earns its place after the platform decision is made. Adopting this package does not help you evaluate whether CheddarGetter is right; it only reduces the cost of using it.
- You are on PHP/Laravel and want the shortest path to a working subscription flow. An official client means the request signing, endpoints, and response shapes are handled for you rather than reverse-engineered.
- Your billing model is straightforward — recurring plans, trials, simple upgrades/downgrades, one-time charges — and does not require usage-based metering, multi-entity tax handling, or revenue recognition.
- You can absorb maintenance risk. With the last release in October 2020, zero dependent packages on Packagist, and modest community size, treat this as vendored code you own, not a dependency you consume. Budget for: verifying PHP 8.x and current Laravel compatibility, checking that HTTP client and Guzzle versions in your lockfile are supported, and writing your own contract tests against the live API. If your team cannot own a fork, this is a poor fit.
- You are wrapping it. Pair it with an internal
BillingGateway interface so the vendor is swappable. That turns the staleness risk into a contained, reversible decision.
Look elsewhere when:
- You are greenfield and uncommitted. Start the provider evaluation with Stripe Billing, Chargebee, Paddle, or Lemon Squeezy/Laravel Cashier, which have active maintenance, first-party Laravel ergonomics, webhook handling, and a support relationship. Choosing CheddarGetter in 2025 on the strength of a 2020 SDK is a decision driven by inertia, not evidence.
- You need Laravel-native DX — service provider, publishable config, facades, events, queued webhook jobs, test helpers. This is a framework-agnostic API client; all of that glue is yours to write and maintain.
- You require vendor-supported SLAs, security patches on a schedule, or SOC 2 evidence tied to an actively maintained SDK. Nothing in a five-year-old release cadence supports that.
- Billing is a core differentiator or a material revenue-risk surface. In that case, the thin-client savings are outweighed by the operating cost of owning an unmaintained integration.
- You are on a non-Laravel PHP stack with no existing CheddarGetter footprint — the value proposition collapses to "generic SDK for a vendor you haven't chosen."
How to Pitch It (Stakeholders)
For executives. Subscription billing is expensive to build and easy to get wrong — proration, failed-payment retries, and invoice correctness are where finance and engineering both lose sleep. This package lets us integrate a billing provider through an official client instead of building a ledger, which compresses a multi-month workstream into a few weeks and moves revenue-generating paid tiers earlier in the roadmap. Cost of adoption is low: MIT-licensed, no per-seat or platform fee, and the integration surface is small. The honest caveat is maintenance: the client's last release was in 2020 and it has essentially no downstream community. We should therefore treat it as code we own — wrap it behind an internal billing interface, budget a small ongoing maintenance allowance, and keep the provider decision reversible. The recommendation is to adopt it only if we have already committed to CheddarGetter as the billing platform; it is a cost-reducer on a decided path, not a reason to choose the path.
For engineering. This is a thin, official HTTP client for the CheddarGetter API — it removes the boilerplate of auth, endpoint construction, and response parsing, and nothing more. There is no Laravel service provider, config publishing, event dispatch, or webhook handling; expect to write an adapter (interface + concrete implementation + DTOs) and a test suite against a sandbox account. Two engineering risks to size before committing: PHP and dependency compatibility against our current Laravel version, since the last tagged release predates recent framework majors; and version pinning, because an unmaintained client will drift from the vendor's API and from our HTTP client's security patches. Mitigations are cheap — pin the version, add contract tests that run in CI against the sandbox, and keep the vendor behind our own interface so a swap is an implementation change, not a refactor. If we adopt, plan to either fork it internally or accept that we are the maintainers.