Recaptcha Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for bot mitigation. Lets us adopt server-side reCAPTCHA token verification as a configuration task instead of custom code, so engineering time goes to product surface (forms, onboarding, checkout) rather than plumbing.
• Where to apply protection. Supports a roadmap decision to cover login, registration, password reset, contact, and checkout forms with a consistent verification path — one dependency, one config surface.
• Dependency/upgrade planning. Release 2.2.0 widens the google/recaptcha constraint to allow 2.x. This is a maintenance release: it reduces the chance of Composer conflicts with other packages and keeps us on a supported version of the underlying client. It does not change behavior, so no feature work or retesting of form flows is required.
• Framework fit check. This is a Symfony bundle, not a Laravel package. It is the right build-vs-buy answer for a Symfony codebase; for a Laravel codebase it is a signal to evaluate a Laravel-native alternative rather than force this in.
• Vendor concentration. Confirms we are standardizing on Google reCAPTCHA. That is a strategic (not just technical) choice given privacy/consent and regional availability considerations, so it should be recorded as a deliberate decision, not a default.

When to Consider This Package

Adopt when:

• The application is Symfony-based and we want config-driven reCAPTCHA verification with minimal custom code.
• We need straightforward server-side verification of a token on a handful of forms, at low-to-moderate volume.
• We already use Google reCAPTCHA and simply want a thin, maintained integration layer.
• We want to stop hand-maintaining our own reCAPTCHA glue code.

Look elsewhere when:

• The stack is Laravel — choose a Laravel-native package; do not adopt this bundle for framework-fit reasons.
• We need advanced bot management (behavioral scoring, rule engines, enterprise SLAs) — this is a thin wrapper, not a platform.
• Privacy, GDPR, or regional constraints argue against sending traffic to Google — evaluate Cloudflare Turnstile or a self-hosted option instead.
• We need heavy v3 score/action orchestration out of the box; verify the exposed configuration before committing.
• Package health is a concern: this is a small, single-maintainer project, so treat it as a replaceable dependency behind our own abstraction.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, no-new-contract way to cut spam and fake signups on our forms. The 2.2.0 release is a compatibility update that keeps us on a supported reCAPTCHA client and avoids upgrade friction — no user-facing change, no added cost, no migration project. The trade-off is a dependency on Google, which carries privacy and consent obligations we should accept deliberately.

For engineering: A thin Symfony bundle wrapping google/recaptcha with configuration for keys and verification. Small surface area, easy to wire in. 2.2.0 only relaxes the google/recaptcha version constraint — no breaking changes, no deprecations, no action needed beyond a normal dependency bump. Because it is small and single-maintainer, wrap it behind our own interface so swapping to Turnstile or a native implementation stays cheap; keys and secrets go through environment configuration as usual.

Bottom line: Worth adopting for a Symfony codebase that only needs standard reCAPTCHA verification; the new release removes a version-pinning headache but does not change the recommendation either way.