Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Laravel Whmcs Up Laravel Package

sburina/laravel-whmcs-up

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Build vs. buy for billing/subscription infrastructure: This package is the integration seam between our Laravel application and WHMCS. Adopting it means we treat WHMCS as the system of record for billing, provisioning, and customer accounts rather than building those capabilities in-house — a decision that should be made deliberately and above the package level, but which this package makes cheap to execute.
  • SSO strategy for the customer portal: The v2.0.0 switch from AutoAuth to CreateSsoToken is a forced roadmap item, not an optional one. AutoAuth was removed in WHMCS 8.1, so any product surface that relied on getAutoLoginUrl() / redirectAutoLogin() has a hard deadline tied to our WHMCS upgrade. This is a "schedule the work now" input, not a "consider later" one.
  • Minimum platform matrix (upgrade scoping): PHP 8.2+, Laravel 10–13, WHMCS 8.1+ becomes our floor. That drives upgrade sequencing across the whole stack and should be reconciled against our existing Laravel/PHP support policy before we commit.
  • Feature feasibility for account-management use cases: The sbGetClients() additions ($orderby, $status) unlock client listing/filtering screens in our own UI without writing custom API calls — useful for support tooling, admin dashboards, and internal CS workflows.
  • Operational resilience as a design input: Configurable timeout (WHMCS_TIMEOUT) and SSL verification on by default are the levers we need to make a synchronous third-party dependency safe. These should inform how we think about degraded-mode behavior when WHMCS is slow or unreachable.
  • Where we invest engineering effort: Because the package now uses Laravel's Http facade and implements rehashPasswordIfRequired(), it aligns with framework conventions we already maintain. That lowers the cost of forking or patching it if we need behavior WHMCS doesn't offer — relevant to any "extend vs. wrap" decision.

When to Consider This Package

Adopt it when all of the following hold:

  • WHMCS is already (or is firmly planned to be) our billing/provisioning system of record, and we need a Laravel application to authenticate against WHMCS client records.
  • We need customers to move between our app and the WHMCS client area without re-authenticating — the SSO path is the primary value here.
  • We are on, or can get to, PHP 8.2+ / Laravel 10+ within the same planning horizon as a WHMCS 8.1+ upgrade. The two upgrades are effectively coupled.
  • We want a maintained integration layer rather than hand-rolling API calls, and we're comfortable with the package's opinionated defaults (session key, URL scheme, SSL on).

Look elsewhere or proceed with caution when:

  • We're pinned below PHP 8.2 or Laravel 10. v2.0.0 offers no path; staying on v1.x means staying on the deprecated AutoAuth flow, which is dead against WHMCS 8.1+. There is no clean middle ground — that's a real constraint, not a footnote.
  • We rely on Lumen. Lumen support was dropped (EOL upstream). This is an architectural fork in the road, not a config change.
  • We use a non-WHMCS billing platform. The package is WHMCS-specific by definition.
  • We need a fully abstracted billing domain layer. This is a thin client/SDK. It exposes WHMCS's data model rather than shielding us from it. If our roadmap anticipates swapping billing providers, we'd want our own anti-corruption layer on top — and should budget for it explicitly.
  • We require vendor-backed SLAs or commercial support. Assess support expectations before betting a revenue-adjacent flow (auth, SSO) on it.

How to Pitch It (Stakeholders)

For executives (one paragraph): We use WHMCS as our billing and customer-account system. This package is the connector that lets our Laravel application log customers in against their WHMCS accounts and hand them into the WHMCS portal without signing in twice. Version 2.0.0 is a substantial modernization release that keeps us aligned with current Laravel and WHMCS versions — it is required work rather than optional polish, because the previous SSO mechanism was removed by WHMCS in 8.1 and the old code path will stop functioning against a current WHMCS install. The cost is a coordinated upgrade (PHP 8.2+, Laravel 10+, WHMCS 8.1+) and a small amount of migration work on our SSO entry points. The benefit is that we stay on a supported integration path, gain better control over how we handle slow/unavailable WHMCS responses, and pick up small but real capabilities (filtered client lookups) that save custom development.

For engineering (the substance):

  • This is a breaking major, not a drop-in. Plan it as a scheduled migration with a migration guide from the README, not a composer update.
  • Three changes will bite in production if missed: SSL verification is now on by default (any environment relying on unverified certs — likely staging or an internal WHMCS host — will start failing); the default session key moved from user to whmcs_user (silent logout / auth-state bugs for anyone reading that key directly); and the default URL scheme is now https://.
  • SSO method swap is the headline work item. getAutoLoginUrl() / redirectAutoLogin() still exist but emit E_USER_DEPRECATED. Treat any deprecation notice in logs as a tracked defect with an owner — the underlying AutoAuth feature is already gone from WHMCS 8.1, so these calls are on borrowed time.
  • Net positive internals: swapping raw Guzzle for Illuminate\Support\Facades\Http means standard fakes, retries, and middleware in tests; rehashPasswordIfRequired() means we can modernize password hashing without a forced reset; the configurable timeout gives us a real knob for a synchronous third-party call.
  • Two things to verify before sign-off: that the supported Laravel range (10–13) lines up with our own upgrade plan, and that our test suite fakes the HTTP layer rather than hitting a live WHMCS instance — especially now that SSL verification is enforced.

Bottom line: Worth adopting, and effectively unavoidable if WHMCS is our billing system of record. Budget it as a platform upgrade with a migration task list, not a dependency bump.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
mehedimi/laravel-amp-mail
happones/laravel-vue-i18n-generator
jwerd/inertia-table
siberfx/flysystem-wasabi
hollyit/token-replace
ippanelcom/laravel-sdk
adachsoft/changelog-linter
adachsoft/collection
payerurl/telegrambot-crypto-payment-instant-payout
dskripchenko/laravel-hybrid-search
riorizkyrainey/lara-ced
mehedimi/static-vel
zharp/zharp
nonsapiens/bigquery-model-sync
lgu-bayambang-ict-office/lgu-laravel-development-standards
andydefer/laravel-support
se7enxweb/flysystem
lampwick/laravel
jeslage/statamic-emojis
micahdshackelford/rmap-laravel