The reCAPTCHA tax on every project
On every site you ship, the same question comes back: does this use Google reCAPTCHA, and do we need a cookie banner for it? reCAPTCHA sends visitor data to the US and sets a cookie, so the honest answer is yes - consent banner, US transfer, and you are the one defending it to the client or their data protection officer. That is a tax you pay on every build.
Wondering how it holds up against reCAPTCHA, hCaptcha, Turnstile and Friendly Captcha? See the full comparison.
Why it fits the way an agency works
Adopt it with zero budget approval
Free covers 5,000 requests a month per site, commercial use allowed. A contact or login form rarely needs more, so you can make it the default across client sites without a single purchase decision.
No cookie banner for the CAPTCHA
The widget sets no cookie and stores nothing on the visitor's device, so no consent is needed. It also sends nothing to the US. One less thing to wire into the consent tool, and one less thing to defend in a privacy review. Other trackers on the site are still your call.
No puzzles for your client's visitors
No traffic-light grids, no "select all the crosswalks". The visitor's browser solves a silent proof-of-work while they fill in the form, so your client's users sail through instead of clicking fire hydrants. Better completion, and no friction you have to explain to the client. This one needs no compliance reason at all.
Client forms do not break at the limit
On paid tiers, going over the monthly quota keeps serving at the same difficulty instead of blocking. No 3am message because a client contact form died at the cap - just an upgrade email when it suits you.
The paperwork a DPO asks for
A pre-signed DPA, EU-only hosting in Nuremberg, and a published sub-processor list. Hand it to the client data protection officer and move on.
An exit that costs an afternoon
A script tag, one data attribute, and a local verification call - no SDK, no proprietary data model. If you ever swap it out, it is an afternoon, not a migration. The continuity terms are written down.
Many client sites, one approach
Three domains on Starter, ten on Growth, unlimited on Business - all under your account. When a client should own the billing, they sign up themselves and you just paste the key.
WordPress is the fastest path in
Most client sites are WordPress, so that is where this lands first. The official plugin protects the login, registration, lost-password and comment forms plus Contact Form 7. Install it, paste the site key, done - no code, no markup, no cookie banner.
Three lines in, on any stack
For everything that is not WordPress, the integration is a drop-in:
<script>window.CAPTCHA_SITE_KEY = 'pk_live_...';</script>
<script src="https://captchaapi.eu/captcha.js" defer></script>
// + add data-captcha to your <form>Server-side, verify the signed attestation locally with the project secret. There is no server-to-server round trip on submit. Full detail in the backend docs.
Where I would point you elsewhere
I run this solo and would rather say so. There is no team dashboard for managing many client accounts in one place yet, no agency rebilling, no third-party accessibility certificate, and no contractual uptime SLA. If a client needs any of those, the bigger vendors have them today. Everything above is what I do have.
The flip side: this is not a weekend project. I run Billify, my own EU B2B invoicing product, on this exact integration. Do not take my word for it - open devtools on the live demo and watch the /challenge call fire.
Make it your default
Free tier, commercial use allowed, no card required. Drop it into your next client build and see how little there is to it.