Weixin Web Laravel Package

Product Decisions This Supports

• Build vs. buy for WeChat login: The package answers a narrow, well-defined question — "how do we let web/desktop users sign in by scanning a WeChat QR code?" — without owning WeChat's OAuth protocol, token exchange, or openid/unionid parsing ourselves. It lets a PM frame the decision as "adopt a thin community driver" versus "staff an in-house WeChat integration," which is a much cheaper comparison than it first appears.
• China market entry and activation: WeChat QR login is the default low-friction identity path for Chinese desktop/web users. Supporting it directly affects top-of-funnel conversion for any product launching into or expanding within mainland China; without it, users face SMS/email registration flows they often abandon. This makes it a launch-blocking dependency for the China web funnel, not a nice-to-have.
• Identity and account-linking strategy: Retrieving unionid (not just per-app openid) is the product-level enabler for recognizing the same person across multiple WeChat applications (web, mobile app, mini program). That is a roadmap decision: do we treat WeChat as a login method, or as the primary identity key for our Chinese user base? The package supports the former cleanly and gives us inputs for the latter.
• Scope containment on the roadmap: This package covers web QR login only. It does not cover native-app WeChat login, mini-program login, in-app-browser OAuth for Official Accounts, or WeChat Pay. PMs should explicitly carve those out of the current milestone rather than letting "WeChat integration" balloon into an unbounded epic.
• Vendor/onboarding lead time as a planning input: The real critical path is rarely the code — it is obtaining a verified WeChat Open Platform enterprise account, an approved website application, a filed (ICP) domain, and passing review. The library's "minimal configuration" story depends on those prerequisites already being satisfied. Budget weeks, not hours, for account and domain approval, and track it as an external dependency with an owner.
• Prioritization and metrics: Authentication is commodity infrastructure. Fund it as platform/enablement work, judge it on login-step conversion, registration completion rate, and login-related support tickets — not on differentiation. If WeChat login is a top-3 acquisition blocker for the China launch, it earns a slot; if not, it waits.
• Maintenance-risk acceptance: With 29 stars and a last release in 2020, this is a single-maintainer, low-adoption dependency. That is a legitimate business decision only if we also decide, up front, that we are willing to fork or vendor the driver if upstream goes stale — a decision PMs should force rather than leave implicit.

When to Consider This Package

Consider it when:

• The product is a Laravel application already using Socialite for other providers. This package is a drop-in driver that follows the standard provider interface, so the marginal integration cost is genuinely low — configuration plus a redirect/callback route.
• The target flow is desktop/web QR-code login against the WeChat Open Platform website application type. That is precisely the gap it fills; Socialite has no first-party WeChat web provider.
• The team has, or can obtain, the WeChat Open Platform prerequisites (verified enterprise account, approved website app, App ID/App Secret, ICP-filed callback domain). Without these, the package cannot be evaluated meaningfully.
• You need openid/unionid and basic profile data and are content with WeChat's limited profile scope — this is not a rich-profile source.
• You can pin the version, cover the flow with tests, and accept a fork/vendor exit plan. Treat it as a component you may have to own, not a managed service.
• Verify first: the supported Socialite major version, the Laravel/PHP constraint, and whether it still resolves against your current stack. The package predates recent Laravel and Socialite majors; "compatible with modern Laravel versions" in the description is a claim to confirm with composer require in a branch, not a given.

Look elsewhere or defer when:

• You need native mobile app WeChat login, mini-program login, or Official Account / in-app browser OAuth. These are different WeChat surfaces with different providers — this package will not serve them, and stretching it is wasted effort.
• You need WeChat Pay, messaging, or user management alongside login. That is a broader WeChat SDK/integration decision, not an OAuth driver decision.
• You require vendor support, an SLA, or a security policy. There is none here; support is whatever your team can provide.
• Your stack is not Laravel/Socialite, or is on a Socialite/Laravel major the driver has not been updated for. The cost of adapting a stale driver can exceed writing a small custom Socialite provider.
• Compliance or data-residency review prohibits a third-party community package on an authentication path, or your security bar requires a maintained dependency with an auditable release cadence.
• The China launch is not funded or dated. WeChat login has real fixed costs (account verification, domain filing, review cycles); do not pay them speculatively.

How to Pitch It (Stakeholders)

For executives: WeChat QR login is the table-stakes sign-in path for Chinese web users, and without it our China funnel leaks at the very first step. Rather than build and maintain WeChat's OAuth protocol ourselves, this package plugs into Socialite — the auth layer we already run — so the engineering cost is small and measured in days, not a quarter. The decisions to approve are: (1) fund WeChat Open Platform account verification and ICP domain filing now, because approval cycles are the real critical path; (2) accept a thin, community-maintained dependency with a known exit plan — we pin it, test it, and can fork it if upstream stalls; (3) scope this milestone to web QR login only, explicitly excluding native app, mini program, Official Account, and payments. Success is measured by login-step conversion and registration completion for Chinese web traffic, plus a drop in login-related support tickets — not by features.

For engineering: This is a Socialite provider for the WeChat Open Platform website application (QR) flow, returning openid, unionid, and basic profile. Integration is the standard Socialite pattern: add the provider, configure App ID/Secret and the callback URL, wire the redirect and callback routes, and map the returned identity to our user model — with unionid as the cross-application key and openid as app-scoped. Before committing, spike it in a branch: confirm the Socialite major and PHP/Laravel constraints resolve (composer require, composer why-not), confirm the package is not abandoned against our framework version, and cover the callback with a test that mocks the WeChat token/profile responses so we are not dependent on live credentials in CI. The last release is 2020, so plan for the possibility of small patches: keep the driver behind our own auth abstraction so a fork or replacement is a one-file change. Log and alert on callback failures separately from generic auth errors — WeChat-specific failures (expired code, scope, domain mismatch) present differently and should be diagnosable without guesswork. Assign an owner and a routine to re-check upstream release cadence each framework upgrade.