Published Tuesday 30th January 2024

Price changes for Google reCAPTCHA product tiers

I received a billing notice email from Google yesterday, titled "[Billing Notice] Price changes for Google reCAPTCHA product tiers". We use various Google APIs and added a billing account a long time ago, when Google Maps integrations switched to mandatory paid plans, and some of the 28 websites that we've hooked up to reCaptcha APIs had ended up attached to this billing account, so the immediate prospect of reCaptcha integrations suddenly accruing costs and auto-billing us was very real!

Google's API dashboards are horrifically convoluted, as I'm sure anybody with multiple websites, billing accounts, and a mix of enterprise and free keys will agree. Figuring out which of our websites actually do require the link up to this billing account, which are using active reCaptcha keys, and which are likely to end up billing us hasn't been easy. I'm not even sure whether any of our websites still use Google Maps - we advocate Leafletjs these days instead, but that's a separate blog post.

Getting to the point - the gist of Google's email is that they're reducing the number of reCaptcha requests you can make on their free tier, down from 1,000,000 per month, to just 10,000 per month. A 99% reduction to the original quota, and this change comes into force on 1st April, just 2 months after this announcement. If you can find your way around the various API dashboards, you'll probably find that 10,000 isn't enough for most websites. That's about 333 daily requests, and bots trying their luck with your registration and contact forms can easily use up that kind of a quota. It isn't clear what happens if you go over this quota either... reCaptcha might just stop working for the rest of the month, breaking your contact forms. Or they might start accruing unexpected costs. If you don't have a billing account hooked up then these costs at least won't automatically charge from your bank account, but you'll still owe them money, and will be contractually obliged to pay it eventually.

In a nutshell, Google reCaptcha is no longer a free captcha service, much like how Google Maps no longer offers free map integrations. They both technically do, but their offerings aren't good enough. Realistically, if you stick with their integrations you're going to end up needing an enterprise tier.

Enterprise tiers are changing too. With the free tier originally working for up to 1,000,000 monthly requests, their enterprise tier logically only billed for requests beyond this quota. Now though, with the drop from 1,000,000 to 10,000 on the free tier, their enterprise tier will begin charging for requests over the 10,000 monthly quota too. They are however dropping from a fee of $40 per 1,000 requests, to just $1 per 1,000.

What this means in real numbers, is that if you already have an enterprise account and your website consumes say... 1,500,000 monthly reCaptcha requests, you would have previously paid for 500,000 requests at $40 per 1,000, so $20,000 per month. Now you'll pay for 1,490,000 requests at $1 per 1,000, so $1,490 which is considerably cheaper than before, but if your website consumes more like 250,000 monthly requests, you would have previously paid nothing and now you're going to be billed for 240,000 of those requests, at a cost of $240 per month.

For big businesses already used to paying for enterprise accounts, this is good news. Google are basically no longer charging you to cover the costs of running their free tier. But for smaller businesses and personal websites, Google reCaptcha just got prohibitively expensive.

Over the coming months, we're going to be swapping out all of our reCaptcha implementations for something else, but we're not yet sure what to replace it with.

We already have in-house captcha mechanics that work well enough as fall-backs for when visitors hit websites without Javascript enabled, or when bots try to circumvent reCaptcha completely, but we understand that people don't like having to complete "Enter the text" or "What's this image?" type captchas, and making a visual captcha that's too complicated for a bot to figure out means making them in a way that's often incompliant with accessibility guidelines, and sometimes too difficult even for somebody with excellent vision to complete.

Google's reCaptcha service, with its invisible integration option and their use of AI to determine whether a visitor is a human or a bot without any need for the person to complete any specific task, was a genuinely excellent offering. Finding, or creating, a reasonably decent alternative is going to be difficult.

I'll likely post an integration tutorial again when we've decided on a way forwards, but in the meantime, some options for those stumbling onto this blog post which we're currently looking into are Cloudflare Turnstile, hCaptcha, and mCaptcha. Decide for yourself whether any of these are a good fit for your websites, or leave a comment if you decide on something else. We're open to suggestions at the moment.

31st January update:

hCaptcha was initially looking like the best contender for us. Their free tier allows up to 1,000,000 monthly requests and although their invisible captcha option requires a premium tier, their pricing seems reasonable. Some of our smaller clients likely wouldn't be able to warrant that fee though, and I've been informed that hCaptcha has accessibility issues which is a clear disadvantage over some of the other offerings. For me, the whole point of invisible captchas is that they're frictionless. Whether you have any disabilities or not, an invisible captcha should be able to authenticate you behind the scenes and present with a minimal, WCAG compliant interactive check in the few cases where it can't. So, sadly, hCaptcha didn't quite cut it for me.

We've instead gone with Cloudflare Turnstile, at least for now. Their free tier is limited to only 10 websites, but they do allow unlimited requests per website, and their captcha can be hidden unless interaction is needed which is basically how reCaptcha v3 works. Turnstile claims to be WCAG AA compliant which I find impressive for any captcha mechanic really, and their Wordpress plugin is straightforward, with options to protect all the core Wordpress forms as well as a bunch of major plugin provided forms, including Contact Form 7 and Woocommerce. Of the 28 websites that were hooked up to our Google account for reCaptcha integration, the 2 that push the most captcha requests through are both Woocommerce websites with Contact Form 7 forms, so the simplicity of migrating combined with the accessibility benefits won me over.

These two websites are now acting as guinea pigs. Both have been migrated to Cloudflare Turnstile, and so far the results seem promising. Some of the other websites we manage will likely be moved over to Turnstile too, but with the 10 website limit, the smaller sites might have to remain on Google reCaptcha for now, while we decide properly on how to proceed.

I've also been conceptualising a bespoke invisible captcha mechanic, which might still be developed as a longer term replacement. My idea is to have a browser-side script generate 10x10 px icons representing the rough mouse/finger movement on protected pages around an imaginary grid, as well as things like the number of per-field keystokes while populating, and this data would be submitted with the rest of the form for analysis against submissions from previous entries. Without giving too much away, in a nutshell the analysis would figure out averages from trusted submissions and request further interaction from any submission that it isn't sure aligns with that average. Data wouldn't contain anything personal or identifiable at all, would be stored in a GDPR compliant way, and would be erased after a set number of subsequent submissions. Just an idea for now.

Photo of Ric

Ric

Ric is a senior web and game programmer with nearly 30 years industry experience and countless programming languages in his skillset. He's worked for and with a number of design and development agencies, and is the proprietor of QWeb Ltd. Ric is also a Linux server technician and an advocate of free, open-source technologies. He can be found on Mastodon where he often posts about the projects he's working on both for and outside of QWeb Ltd, or you can follow and support his indie game project on Kofi. Ric also maintains our Github page of useful scripts.

Blog posts are written by individuals and do not necessarily depict the opinions or beliefs of QWeb Ltd or its current employees. Any information provided here might be biased or subjective, and might become out of date.

Discuss this post

Nobody has commented yet.

Leave a comment

Your email address is used to notify you of new comments to this thread, and also to pull your Gravatar image. Your name, email address, and message are stored as encrypted text. You won't be added to any mailing list, and your details won't be shared with any third party.

This site is protected by reCAPTCHA and the Google Privacy Policy & Terms of Service apply.