Laravel Laravel Package

Product Decisions This Supports

• Feature decisions — bot mitigation on public, unauthenticated surfaces. Contact, signup, password-reset, guest checkout, newsletter, and lead-gen forms are the highest-abuse, lowest-friction-to-attack flows. This package makes "add CAPTCHA" a one-package sprint item rather than an integration project, so it primarily supports prioritization of abuse-prevention work you'd otherwise defer.
• Build vs. buy, with the emphasis on buy the integration, not the service. The package is a thin SDK over a hosted verification API. Adopting it is really two decisions: (a) buy rather than build CAPTCHA logic (clear yes — never build this), and (b) buy captchaapi.eu rather than a mainstream provider. The SDK only lowers the switching cost of (b); it doesn't answer it.
• Roadmap input for Laravel/Livewire-heavy products. Native WithCaptcha trait, <x-captchaapi::livewire-form> wrapper, and event-mode dispatch are the differentiated part. If your roadmap is Livewire 4 forms, this removes the usual "CAPTCHA doesn't play well with Livewire validation cycles" tax — including the Fortify double-validation edge case, which is called out and testable.
• Compliance-driven product positioning. EU-hosted (Hetzner Nuremberg), no cookies, no tracking, no Google data transfer. For EU-facing B2B SaaS, DACH-market products, public-sector-adjacent buyers, or brands whose pitch includes privacy, this supports a "GDPR-compliant by default" claim that reCAPTCHA requires legal workarounds to make.
• Conversion/funnel decisions. Proof-of-work is invisible to legitimate users — no image grids, no audio fallback decision, no "I can't solve this" support load. This is a conversion and accessibility argument, not just a security one. The opt-in status element (six states, default colors, CSS-overridable via data-captcha-no-color) supports designing the waiting/error UX rather than bolting it on.
• Risk posture decisions you can put in writing. fail_open defaults to true (public forms) and can be flipped to false for login/payment — that is a documented, per-environment product risk policy, not an implicit one. Likewise CAPTCHAAPI_ENABLED=false as a permanent kill switch keeps local/CI/staging clean without branching markup.
• Release and ops decisions. Dashboard-driven secret rotation with an overlap window means no hard-cutover deploy, which de-risks a security-sensitive launch step. Octane safety (stateless verification, request-scoped memo, test-only fake state) is a real constraint if you run Swoole/RoadRunner/FrankenPHP.
• Delivery-friction decision. FakeCaptchaapi::enable() plus enforceSingleUse() means feature tests and CI don't need live keys or network calls, and you can actually test the single-use contract instead of silently bypassing it. This is the kind of detail that decides whether a security control survives contact with a fast-moving team.

When to Consider This Package

Consider it when most of these are true:

• You're on Laravel 12 or 13 with PHP 8.2+ (this is a narrow, current-version target — deliberately so, but it caps your upgrade flexibility).
• Data residency or DPA friction is a genuine blocker, or EU hosting is a differentiator you'd otherwise have to argue for.
• Your forms are Livewire-first; that's where the package earns its keep over raw HTML integration.
• You want the whole thing wired in under a day: config publish, two env vars, a Blade tag, a validation rule.
• You're comfortable depending on a single external SaaS endpoint with a 5s default timeout and a documented fail policy.
• You can absorb vendor-immaturity risk — 1 GitHub star, 0 dependents, first releases in mid-2026 — by wrapping it behind your own interface so swapping providers is a one-file change.

Look elsewhere when:

• You need self-hosted or zero-third-party-call CAPTCHA (this is hosted-only; base_url is overridable but you're still calling a vendor).
• You're on Laravel 10/11 or PHP 8.1 and can't move — there's no fallback path documented.
• You need the network effect of a mainstream provider (reCAPTCHA/Turnstile/hCaptcha) or enterprise SLAs, SOC 2 attestations, uptime commitments, and a support contract. A 1-star package cannot offer vendor assurance; only MIT source auditability.
• You need proven WCAG conformance or an accessibility audit trail for the widget — the six-state status UI is thoughtful, but the README documents styling, not conformance.
• You're cost-sensitive at high volume and can't yet price the per-verification model against the bot pressure you actually see.
• Any stakeholder requires a named, established vendor in the security stack — that's a procurement reality this package won't clear today.

Recommended gate: timebox a spike, wrap the rule behind an internal BotCheck abstraction, and keep a documented fallback provider. Do not let the Blade component and the captcha validation alias leak into hundreds of templates before the vendor question is settled.

How to Pitch It (Stakeholders)

To executives:

We have a recurring abuse exposure on every public form, and our EU customers' legal teams push back on Google-hosted CAPTCHA. This is a drop-in Laravel package for an EU-hosted, GDPR-compliant CAPTCHA that's invisible to real users — no puzzles, so we don't trade conversion for protection. It's MIT-licensed, the integration is roughly a day of engineering, and there's a documented kill switch and fail-open policy so a vendor outage can't block our signups. The vendor is new and small, so the proposal is a timeboxed pilot behind an internal abstraction with a fallback provider — low cost to try, no lock-in if it doesn't hold up.

To engineering:

composer require captchaapi/laravel, publish config, two env vars. Blade: <x-captchaapi::widget /> in the layout plus data-captcha on the form; validate with new ValidCaptcha or the captcha string alias. Livewire: use WithCaptcha and validateWithCaptcha() — the wrapper handles the event-mode dispatch and hidden input. It's Octane-safe (stateless verify, per-request memo, fake state throws outside testing), FakeCaptchaapi::enable() gets you green tests without network calls, and enforceSingleUse() lets you prove Fortify's double-validation doesn't quietly bypass the check. fail_open is configurable per environment — default true for public forms, flip to false for login/payment. Secret rotation has an overlap window so no hard-cutover deploy. Small codebase, MIT, PHPStan 8, Pest — auditable in an afternoon.

To legal / DPO:

No cookies, no tracking, no Google. Data stays in the EU (Hetzner Nuremberg), and verification is server-to-server with the secret never reaching the browser. Still required from us: a DPA with the vendor and a retention answer for verification metadata — the README documents the architecture, not the data-processing terms, so that's an open item before production.