Recaptcha Laravel Package

Product Decisions This Supports

• Abuse mitigation on high-value funnels. reCAPTCHA v3 is score-based and invisible, so it's most useful where you want bot/fraud suppression without adding friction: signup, login, password reset, checkout, contact/lead forms, coupon and promo abuse, review/comment spam. This package is the plumbing for that decision in a Laravel app, not a strategy in itself.
• Friction vs. conversion trade-off. Because v3 returns a score rather than a challenge, the real product decision is where you set the threshold and what happens on failure (block, silently drop, queue for review, step up to email verification, or escalate to a visible challenge). This package gives you the config surface to express that policy; the policy is yours to own.
• Build vs. buy vs. use-what-Laravel-gives-you. Laravel already ships rate limiting, throttling middleware, and honeypot-style validation. A PM should treat reCAPTCHA as one layer in a stack, not the answer. If the abuse problem is credential stuffing, throttling and breached-password checks may buy more than a score check.
• Roadmap optionality for bot defense. If the roadmap includes reCAPTCHA Enterprise, Cloudflare Turnstile, or hCaptcha (e.g., for privacy/GDPR reasons), the decision to adopt this specific wrapper is a decision to defer a small refactor. Isolate it behind an internal interface now, or accept the later swap.
• Vendor and privacy exposure as a product decision. reCAPTCHA sends visitor signals to Google. For EU/UK traffic or regulated customers, that's a consent and DPA conversation, not just an engineering one. Choosing v3 here commits you to that conversation.
• Where NOT to spend effort. Low-risk, low-value forms (newsletter, search) rarely justify the integration and the false-positive support burden. Scope the rollout.

When to Consider This Package

Consider it if:

• You're on a Laravel version from the ~2020–2021 era (Laravel 6/7/8) and need a v3 wrapper today, with a small team and no appetite for writing ~100–200 lines of glue.
• You want the conventional Laravel affordances — config keys, a validation rule, a Blade directive/component — and a MIT license with no commercial strings.
• The blast radius is genuinely small: one or two forms, and you're comfortable that the dependency is effectively frozen.

Signals to weigh heavily before adopting:

• Maintenance risk is the headline. Last release Feb 2021, 21 stars, low composite score. Assume no upstream fixes. Verify Laravel 10/11 and PHP 8.2+ compatibility yourself; do not assume it.
• Verify the actual surface area. Confirm what it really provides (config, validation rule, view directive, score threshold) versus what you'd have to write anyway. If it's a thin wrapper, the switching cost later is low — but so is the value now.
• Supply chain and CI. An unmaintained package is a permanent line in your dependency audit. Pin it, lock the version, and be ready to fork.

Look elsewhere (or build in-house) if:

• You need reCAPTCHA v2 checkbox/invisible, reCAPTCHA Enterprise, hCaptcha, or Cloudflare Turnstile.
• You need current Laravel/PHP support, active security response, or a maintained release cadence.
• You operate under strict GDPR/privacy constraints where Google-hosted challenges are a blocker.
• Accessibility is a hard requirement — reCAPTCHA has known assistive-technology friction, and v3's invisible scoring can unfairly penalize privacy-hardened or shared-network users.
• You want a provider-agnostic abstraction from day one; a package this thin is cheaper to own than to depend on.

How to Pitch It (Stakeholders)

To executives (one paragraph): We need a cheap, low-friction bot defense on a handful of forms, and this is a small MIT-licensed Laravel wrapper around Google reCAPTCHA v3 that gets us there in days rather than weeks. The caveat is that it hasn't been updated since early 2021 and has a tiny user base, so we should treat it as a short-lived component: pin the version, isolate it behind our own interface, and budget a half-day to fork or replace it when we move to a newer Laravel version or a different provider. The cost of being wrong is small because the package is thin and the integration is contained to a few forms.

To engineering: This is a convenience wrapper, not architecture. Before we commit, confirm (a) it installs and passes tests on our Laravel/PHP versions, (b) what it actually gives us beyond a config file and a validation rule, and (c) that we can swap the provider without touching controllers. Wrap it in our own BotCheck contract, keep the score threshold in our config (not hardcoded), and log the score and outcome on every protected submission so we can tune the threshold from data. Assume no upstream patches — pin the version, note the fork path in the ADR.

What we'd measure after launch: score distribution per protected form, false-positive rate on legitimate users (support tickets, failed signups), drop-off delta on protected vs. control forms, and the volume of abuse actually stopped. If the false-positive cost outweighs the abuse reduction at our chosen threshold, we lower the intervention (log-only or review queue) rather than removing the check — and we revisit the provider choice in the next planning cycle.