Laravel H Captcha Laravel Package

Product Decisions This Supports

• Abuse-prevention features: Adding hCaptcha to signup, login, password reset, contact, waitlist, and checkout forms to cut bot-driven account creation, credential stuffing, and spam — the package provides the server-side verification step these flows need.
• Build vs. buy: Replaces a small but recurring piece of custom code (token verification, error handling, config wiring, testing fakes) with a maintained MIT wrapper. The build cost is low, but so is the buy cost — this is a "buy to avoid distraction" decision, not a strategic one.
• Vendor strategy / privacy roadmap: Choosing hCaptcha over reCAPTCHA is a product decision about third-party data exposure and Google dependency. This package makes that decision cheap to execute and cheap to reverse.
• Cost and accessibility decisions: hCaptcha's pricing and accessibility options (including cookie-consent-free modes) can be evaluated against reCAPTCHA without a large engineering commitment, supporting pricing-page or signup-conversion experiments.
• Sequencing on the roadmap: Because integration effort is a few hours, this can ride along with any form/onboarding work already scheduled rather than occupying its own roadmap slot. Useful as a low-risk "harden the funnel" line item bundled into a security or growth epic.
• Risk posture: Low blast radius — it wraps a stateless HTTP verification call, so it can be feature-flagged per form and rolled back without data migration or schema change.

When to Consider This Package

Adopt when:

• You are on Laravel (PHP) and want server-side hCaptcha verification with minimal code.
• You want configuration through .env (site key / secret) rather than hardcoded values, so the same codebase works across local, staging, and production.
• You need the verification half only — you're rendering the widget yourself in Blade, Livewire, Inertia/Vue, or React, and just need a trustworthy server check.
• You want something small enough to read end-to-end in a review and fork if abandoned; MIT license permits this.
• Your team has no appetite for owning captcha plumbing across several forms.

Look elsewhere or pause when:

• Adoption signal is weak. 21 stars and 0 dependents means almost no third-party validation. Treat it as "audit before adopting," not "proven dependency." Read the source and its tests; it should be small enough that this is an afternoon, not a project.
• Framework compatibility is unverified. Confirm the release line actually supports your Laravel version (and PHP version) before committing; a package that lags Laravel majors becomes a maintenance tax at upgrade time.
• You need more than verification. If you want opinionated Blade components, Livewire/Inertia bindings, multi-provider abstraction (reCAPTCHA + hCaptcha + Turnstile behind one interface), or first-party SLA support, this isn't that — use the official hCaptcha SDKs or a broader captcha abstraction.
• You're not on Laravel, or you're on a framework where a two-line HTTP client call is genuinely simpler than a dependency.
• Supply-chain policy is strict (e.g., required maintainer responsiveness, security disclosure process, signed releases). A single-maintainer package with low visibility may fail procurement review regardless of code quality.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) integration that lets us put bot protection on our highest-risk forms — signup, login, password reset — without building or maintaining that logic ourselves. It also gives us a credible, lower-data-exposure alternative to Google reCAPTCHA, which matters for privacy positioning and enterprise questionnaires. Estimated effort is under a day, there's no license cost and no vendor lock-in, and it can be enabled per form and switched off instantly if it hurts conversion.

To engineering: It's a thin Laravel wrapper around hCaptcha's server-side siteverify call — config-driven credentials via env, a validation rule and a facade/helper for the verification step, and test fakes so our feature tests don't hit the network. It's small enough to read fully in review and fork if needed. The honest caveats: low community adoption (≈21 stars, no known dependents) and we must verify it supports our current Laravel/PHP versions before merging. Plan is to wrap it behind our own small interface so swapping to Cloudflare Turnstile or the official SDK later is a one-file change, and to enable it form-by-form behind a config flag so we can measure conversion impact and roll back without a deploy.

To design/growth: We control the widget placement and can start with the lowest-friction configuration, then tighten the challenge difficulty only if abuse persists. Expect a measurable but usually small conversion cost on signup; we should instrument submit-to-success rates before and after per form.