Altcha Laravel Package

Product Decisions This Supports

• Build vs. buy for bot mitigation on public forms. ALTCHA is a self-hosted, MIT-licensed proof-of-work challenge library — the "buy" side of the decision costs ~zero in licensing and replaces a paid CAPTCHA subscription or a bespoke in-house challenge implementation. The PM decision becomes "integrate a small dependency" vs. "build and maintain crypto + challenge lifecycle ourselves."
• Privacy and compliance roadmap. Because verification is cryptographic and self-hosted, no user data or behavioral telemetry leaves your infrastructure. This directly supports GDPR/CCPA positioning, DPIA simplification, and removal of third-party cookie/consent dependencies that Google reCAPTCHA and hCaptcha introduce on signup, login, contact, and lead-gen forms.
• Vendor and lock-in policy. Choosing this over reCAPTCHA/hCaptcha is a strategic decision to avoid a Google/Meta-adjacent dependency on the critical path of every public form. Also relevant if you have customers or regions where Google services are blocked, unreliable, or politically undesirable.
• Unit economics of abuse protection. Self-hosted, no per-request billing — attractive for high-volume free tiers, public APIs, or anonymous endpoints where per-captcha pricing scales badly. Supports decisions about rate-limiting strategy and abuse budgets for free/anonymous traffic.
• Feature/experiment decisions on form conversion. A drop-in alternative lets you A/B test friction (invisible vs. checkbox-style challenge, difficulty tuning) against incumbent CAPTCHA to measure signup/lead conversion impact — a common, quantifiable PM win.
• Deployment topology decisions. No outbound network dependency means it works in air-gapped, on-prem, VPC-restricted, and regulated environments where third-party CAPTCHA scripts are blocked by CSP or security policy.
• Mobile/API-surface decisions. The library is framework-agnostic PHP, and as of v2.3.0 its challenge signing is byte-for-byte compatible with altcha-lib (JS) — the same challenge/verify logic backs a Blade form, a JSON API for a mobile client, or a headless SPA, and challenges can be issued in one runtime and verified in another. That widens the addressable surface from "Laravel web forms" to "any client we ship."
• Cross-language / mixed-runtime architecture. Because PHP-issued challenges now verify in JS and vice versa, the PM can decide to put the challenge endpoint on the PHP monolith while a Node/edge service or SPA performs part of the flow — without committing to a single runtime for the whole abuse pipeline.
• Security posture and release-risk management. v2.3.0 flips verification to fail-closed when no HMAC secret is configured. That is a genuine security improvement (previously unsigned or tampered challenges — including client-chosen keyPrefix or cost — could verify), but it is a breaking change shipped in a minor version. It informs a policy decision: pin exact versions, read changelogs as release gates, and treat this dependency as one requiring a named owner rather than passive "it's just a library" adoption.

When to Consider This Package

Consider it when most of the following hold:

• You already own a Laravel/PHP stack and want protection at the framework layer rather than a hosted vendor.
• Your threat model is commodity bots — credential stuffing scripts, form spam, scraping, signup farming — not a determined, well-resourced adversary.
• Privacy, data residency, or third-party-script policy is a stated requirement (regulated industry, EU customer base, strict CSP, security review that flags Google scripts).
• You can absorb a thin integration layer. This is a library, not a Laravel package: expect to write a service provider, config, Blade component, middleware, and a replay/expiry strategy yourself. There is no publishable config, no facade, no queue/observability hooks out of the box.
• You have engineering appetite for cryptographic lifecycle details — challenge expiry, HMAC secret rotation, single-use enforcement, difficulty tuning, and graceful fallback for no-JS/accessibility users. As of v2.3.0 the HMAC secret is mandatory on every verifying server; there is no longer an unsigned mode to "add later."
• You want a client/server contract that spans languages. Signing is now canonical-JSON compatible with the JS implementation, so multi-runtime or SPA/mobile front ends are a realistic design target.
• Traffic volume makes per-request CAPTCHA pricing or vendor rate limits painful.

Look elsewhere when:

• You need enterprise bot management — device fingerprinting, behavioral scoring, ML risk engines, managed rulesets, or protected mobile SDKs. ALTCHA is a challenge primitive, not a bot-management platform.
• You need a supported, SLA-backed vendor with an escalation path and indemnities. MIT + ~115 stars + 0 known dependents signals an early-stage ecosystem with single-maintainer risk — and v2.3.0 demonstrates the maintainer will ship breaking changes in patch/minor releases under a 2.x line. Treat it as a dependency you may have to fork and own.
• You cannot tolerate coordinated upgrade windows. Challenges issued before the upgrade that carry float-formatted data, or that were signed without a secret, will fail verification after deploy. There is a real, if short, in-flight-challenge cliff that must be planned for (flush, dual-verify, or accept a brief re-challenge for users mid-form).
• You want turnkey Laravel DX today. Without a mature first-party Laravel wrapper, the integration cost is real engineering time and a permanent maintenance line item — that may erase the "buy" savings at small scale.
• You face high adversarial pressure or targeted abuse where proof-of-work is trivially outsourced to solver farms.
• Your team cannot own it long-term. If nobody will own secret rotation, version pinning, semver-risk review, and upstream vulnerability monitoring, a hosted vendor is the lower-risk call.
• Accessibility and progressive enhancement are hard requirements that you cannot resource — third-party vendors usually ship polished fallbacks; here you build them.

How to Pitch It (Stakeholders)

To executives: We can replace our paid, third-party CAPTCHA with a small, MIT-licensed, self-hosted component. Benefits: no per-request licensing cost, no user data leaving our systems (a clean GDPR/privacy story), no dependency on Google on every public form, and it works in restricted/on-prem environments. The latest release (v2.3.0) is a security tightening: verification now fails closed unless a signing secret is configured, and challenge signatures now interoperate with the JavaScript implementation — meaning one abuse-protection design can serve web, SPA, and mobile clients. Risks: the project is early-stage (small community, no meaningful adoption footprint, thin tooling) and has just shipped breaking changes in a minor version, so we would own the Laravel integration, the upgrade coordination, and the long-term maintenance — an estimated [X engineer-weeks] of build plus ongoing ownership. Recommendation: pilot it behind a flag on one low-risk public form, require an exact version pin and a named owner, measure bot-block rate and conversion against the incumbent, then decide on a broader rollout. Treat the integration as an internal abstraction so we can swap providers if the project stalls.

To engineering: Framework-agnostic PHP library for generating and verifying signed proof-of-work challenges — no service provider, config, or Blade helpers, so we build the Laravel glue: a config/secret, a challenge endpoint, a validation rule or middleware, and a front-end widget. v2.3.0 is breaking under a minor version number. Concretely: verifySolution now always fails without hmacSignatureSecret, so every environment that verifies must have the secret wired into config before deploy (staging included — expect silent test failures otherwise); expiresAt is now int|float|null with 0 meaning no expiry and sub-second precision (drop any assumption of a 1s grace window); canonical JSON now matches altcha-lib JS byte-for-byte, so data containing floats may sign differently and pre-upgrade in-flight challenges will fail; toArray()['data'] returns a stdClass when empty or list-shaped, which will surface as array-access bugs in our validation code; and createChallenge()/toCanonicalJson() now throw JsonException on invalid UTF-8 instead of signing an empty string — that needs a catch path. Plan the rollout: pin the exact version, deploy secret config first, decide how to handle in-flight challenges (re-challenge is acceptable for a form), and add a regression test that asserts unsigned challenges are rejected. Keep it behind a CaptchaProvider interface with a vendor implementation and monitor upstream and CVEs. Main design questions we need answered: challenge difficulty vs. conversion, expiry and single-use enforcement, secret rotation, and a no-JS/accessibility fallback.