Cloud Recaptcha Enterprise Laravel Package

Product Decisions This Supports

• Build vs. buy on bot/abuse defense. This package is the buy-side plumbing: it gives you programmatic access to reCAPTCHA Enterprise's risk scoring, so the decision it informs is whether you pay Google for fraud detection instead of staffing an in-house rules/ML effort.
• Where in the funnel to place friction. Because it exposes createAssessment per-action, you can instrument specific surfaces — signup, login, checkout, promo redemption, review submission, password reset — rather than gating the whole app. That's a product decision about conversion loss vs. abuse loss, and this library makes per-surface scoring cheap to prototype.
• Threshold and enforcement policy. The score returned per assessment maps to allow / challenge (2FA, email verify) / block. PM owns that policy; the package supplies the raw signal and the annotateAssessment feedback loop needed to tune it over time.
• Account-takeover and ATO roadmap items. Enterprise features (account defender, password leak detection, related-account grouping) are the differentiators over reCAPTCHA v3, and they're reachable through this client — so it directly enables roadmap items that v3 cannot support.
• Key lifecycle and multi-surface rollout. Site keys are a first-class resource here (createSiteKey, listKeys, getKey). That supports shipping separate keys per platform (web/iOS/Android) and per environment, which is a real operational decision when you don't want prod keys in staging.
• WAF / edge integration strategy. Enterprise assessments feed Cloud Armor and third-party WAF integrations. If a roadmap item is "stop bots at the edge," this is the data source that makes it viable.
• Vendor concentration review. Adopting this deepens the GCP dependency (credentials, IAM, billing, data egress). That's a procurement/architecture decision, not just an engineering one.

When to Consider This Package

Adopt the underlying service when:

• You already run on GCP (Cloud Run/GKE/App Engine, Cloud Armor) and can use Application Default Credentials without new secrets infrastructure.
• You need graded risk scores and a tuning feedback loop, not just a pass/fail captcha.
• Abuse is costing real money — credential stuffing, card testing, scraping, promo abuse — enough to justify per-assessment spend.
• You're migrating off reCAPTCHA v3 and want the enterprise scoring model, SLAs, and support path.
• You need ATO-specific signals (leaked credentials, account defender) that free tiers don't offer.
• You have compliance/audit requirements that a vendor with a DPA and enterprise terms satisfies better than a self-hosted alternative.

Look elsewhere when:

• You want a drop-in Laravel experience. This is a generated GAPIC client — no service provider, no config publish, no Blade directive, no validation rule. You will write that layer: a wrapper service, a form request rule, timeout handling, and a fail-open/fail-closed policy. Budget for it.
• Abuse is ordinary contact-form spam. reCAPTCHA v3 (free) or Cloudflare Turnstile (free, privacy-friendlier, no Google dependency) will do, with less legal review.
• You're cost-sensitive at high volume. Assessments are billed per unit beyond a monthly free allotment; on a high-traffic consumer funnel this becomes a line item that scales with traffic, not with revenue.
• You have data-residency or consent constraints that sending behavioral signals to Google complicates. European consumer apps, children's products, and healthcare warrant legal review first.
• You're not on GCP and don't want a second cloud's IAM/billing surface just for captcha.
• You need offline/self-hosted inference or a deterministic, auditable scoring model.

Treat the package signal itself with care: 13 stars and zero dependents is not a viability problem — it's an auto-generated Google client with a regular release cadence, and its reliability comes from the release pipeline, not the community. But it does mean you will find no Laravel-specific examples, no Stack Overflow corpus, and no third-party tutorials. Your team's onboarding cost is on you.

How to Pitch It (Stakeholders)

To executives: This is Google's official PHP client for reCAPTCHA Enterprise, their paid bot and fraud detection service. It is a component, not a product — roughly a week of engineering to wrap it into something our application can use cleanly. The business case is not the library; it's whether abuse is currently costing us more than the assessments and the integration. Bring numbers: fake account volume, chargeback rate from card testing, promo leakage, support hours on spam. If those are small, we should stay on the free tier or Turnstile and revisit. If they're material, this gives us graded risk scores, a tuning loop, and account-takeover signals we cannot get from reCAPTCHA v3.

To engineering: Low-level generated client — auth via ADC, gRPC with REST fallback, one class per API surface. No framework integration is provided or implied. We'd own: a thin service wrapper, a form-request validation rule, secrets handling for site/API keys, an explicit timeout and fail-open vs. fail-closed decision per endpoint, and structured logging of score + action + outcome so we can tune thresholds. Also flag the extra network hop on protected paths — it's on the critical path for checkout and login, so it needs latency budgets and a circuit breaker. And note the vendor lock-in: credentials, billing, and data flow all land in GCP.

The recommendation in one line: pilot on a single high-abuse surface (signup or login) behind a feature flag, instrument allow/challenge/block outcomes for 30 days, then decide on broader rollout based on measured abuse reduction against conversion impact. Don't adopt org-wide on the strength of the vendor's brand alone.