Start with the big picture before we meet the details.

The simple definition

reCAPTCHA Enterprise is a managed fraud and abuse detection service from Google Cloud. You add a small piece of code to your web page or mobile app. Each time an important action happens, that code collects signals and produces a token, which is a short-lived sealed note. Your server sends the token to Google, and Google answers with a risk score between zero and one, plus reasons. A score near one means the visitor looks like a genuine person. A score near zero means it looks like a bot or an abuser.

Why it exists

Automated programs, called bots, can attack a website very quickly. They can guess passwords, create thousands of fake accounts, scrape prices, buy out limited stock, or test stolen credit cards. Traditional puzzles such as “type the squiggly letters” annoy real users and are now often solved by machines. Modern detection looks at behaviour and context, and keeps the experience smooth for real people.

Where it is used

Teams protect login pages, registration forms, password resets, checkout and payment pages, comment and contact forms, voucher and loyalty systems, ticketing and booking flows, and any interface that bad actors could abuse.

To defend your site, first learn the common attacks.

What is a bot, really?

A bot is a program that acts like a user, but much faster and in huge numbers. Simple bots call a web address directly with no browser. Smarter bots drive a real browser and imitate clicks and typing. The cleverest mix automation with real human help, such as paid workers who solve puzzles. Detection must therefore look at many signals together and not rely on any single test.

Why puzzles alone are not enough

Distorted-letter puzzles and picture puzzles slow down real people and can be defeated by modern machine learning or human click farms. They also hurt accessibility. The modern approach is to score risk in the background and only ask for extra proof when the risk is unclear or high.

Six simple ideas explain most of what you will see in the console and the documentation.

Actions

Each time you ask for a token, you give it an action name, such as “login”, “signup”, or “checkout”. The name travels inside the token. Your server later checks that the action in the token matches the action it expected. This stops a token created for a harmless page from being reused on a sensitive one. Use clear, consistent names, and one for each important step.

The token’s life

• Short life. A token is valid only for a couple of minutes.
• Single use. Once your server has checked it, it cannot be reused.
• Created per action. Make a fresh token at the moment of the action, not once when the page loads.
• Checked on the server. Never trust the browser alone, because attackers control their own browsers.

Follow one protected action from the user’s click to your decision.

flowchart LR
  A["User action in browser or app"] --> B["reCAPTCHA script or mobile SDK"]
  B --> C["Collects signals and requests a token"]
  C --> D["Google reCAPTCHA Enterprise service"]
  D --> E["Token returned to the page"]
  E --> F["Your web server receives the form and token"]
  F --> G["Create assessment request"]
  G --> D
  D --> H["Verdict with score, reasons, and action name"]
  H --> I["Your decision logic"]
  I --> J["Allow, challenge, or block"]
  I --> K["Annotate the outcome later"]
  K --> D
    

sequenceDiagram
  participant U as User Browser
  participant R as reCAPTCHA Service
  participant S as Your Server
  U->>U: User presses the login button
  U->>R: Execute with site key and action login
  R-->>U: Token
  U->>S: Send credentials and token
  S->>R: Create assessment with token and site key
  R-->>S: Valid token, action match, score, reasons
  alt Score is high
    S-->>U: Continue with normal login
  else Score is middling
    S-->>U: Ask for extra proof such as a second factor
  else Score is low
    S-->>U: Block or slow the request
  end
  S->>R: Later annotate the result as legitimate or fraudulent
    

What the signals are

The service looks at many things together: how the page was reached, characteristics of the browser and device, patterns in how pointers and keys are used, the network the request comes from, how many similar requests appeared recently, and patterns it has learned from the whole internet. It also learns from your own feedback. No single signal decides. The score is a blended judgement.

What the verdict contains

A site key can work in several ways. Choose the one that fits each place.

flowchart TD
  A["What are you protecting"] --> B{"Web page or mobile app"}
  B -->|"Mobile app"| C["Mobile key for Android or iOS SDK"]
  B -->|"Web page"| D{"Can your server make assessments"}
  D -->|"No backend or very simple site"| E["Express key with limited features"]
  D -->|"Yes"| F{"Prefer invisible checks or a visible box"}
  F -->|"Invisible score based"| G["Score based key"]
  F -->|"Visible challenge"| H["Checkbox key"]
  A --> I{"Protected by a web application firewall"}
  I -->|"Yes"| J["WAF key with Cloud Armor or a supported partner"]
    

Domain and app settings

Each key is limited to the website domains or app identifiers you list. A token made on any other domain is rejected, which stops others from borrowing your key. Keep these lists exact and tidy, and add every real domain, including test environments, using separate keys for production and testing.

A clear order of work prevents most beginner mistakes.

Start in a safe mode

Do not switch on blocking on day one. First observe. Create assessments for every protected action, log the scores and reasons, but allow everything. After a week or two of real traffic, study the score distribution. Genuine traffic usually clusters at high scores. Bots and abusers form a separate cluster at low scores. Choose thresholds from these real pictures, then start with gentle actions such as adding a challenge, before moving to blocking.

Where to place the checks

• Login. Protects against password guessing and stuffing.
• Sign-up. Protects against fake accounts and promotion abuse.
• Password reset and email change. Common steps in account takeover.
• Checkout and payment. Protects against card testing and stolen cards.
• Search and price pages. Where scrapers work, often better handled with rate limits plus scores.
• Forms and comments. Reduces spam.

The score is advice. Your rules turn it into action. Careful rules protect both security and sales.

flowchart TD
  A["Assessment received"] --> B{"Token valid, host and action match"}
  B -->|"No"| C["Reject the request"]
  B -->|"Yes"| D{"Score level"}
  D -->|"High such as 0.7 and above"| E["Allow normally"]
  D -->|"Middle such as 0.3 to 0.7"| F["Step up: second factor, checkbox, or email check"]
  D -->|"Low such as below 0.3"| G{"How risky is the action"}
  G -->|"Very risky such as payment"| H["Block and log"]
  G -->|"Less risky"| I["Slow down, queue for review, or show a harmless delay"]
  E --> J["Annotate outcome later"]
  F --> J
  H --> J
  I --> J
    

The cost of mistakes

Every threshold balances two errors. A false positive blocks a real customer, which costs sales and goodwill. A false negative lets a bad actor through, which costs fraud losses. The right balance differs by action. For a newsletter sign-up, a few bots do little harm, so be gentle. For a payment page, a stolen card does great harm, so be stricter and add extra checks.

Responses beyond block

• Step-up verification. Ask for a one-time code, a checkbox, or an email confirmation.
• Slow down. Add delays that hurt bots at scale but barely affect a single person.
• Silent handling. Accept the request but hide the result from the attacker, or place the action in a review queue.
• Limit what is allowed. Allow browsing but not purchase, or allow sign-up but block promotions.
• Flag for review. Let a human look at a few borderline cases.

The more you tell the service about outcomes, the better it protects you.

The first score is a general judgement. To become really good for your own site, the service needs feedback. After an assessment, when you later learn what really happened, you send an annotation. For example, “this signup turned out to be genuine”, “this order was later charged back as fraud”, or “this login used a correct password”. With enough annotations, the service builds a site-specific view and tunes scores to your traffic, sometimes improving accuracy noticeably.

flowchart LR
  A["Action happens"] --> B["Assessment and score"]
  B --> C["Your decision"]
  C --> D["Real outcome becomes known later"]
  D --> E["Annotate as legitimate or fraudulent"]
  E --> F["Site specific model improves"]
  F --> B
    

What you can annotate

• Legitimate or fraudulent. The main label for the action.
• Reasons for the label. Examples include chargebacks, a confirmed customer, a correct password, a failed verification, or an incorrect password.
• Account and identity hints. A stable, hashed account identifier lets the service connect actions to the same account over time, without exposing personal details.

Habits that make annotation work

• Store the assessment identifier. Keep it with the order or account record so you can annotate later.
• Annotate promptly and consistently. Build it into the process for chargebacks, support tickets, and verification results.
• Include the good cases too. Confirming legitimate actions matters just as much as flagging fraud.
• Hash identifiers. Never send raw emails or phone numbers when a hashed form is accepted, unless your privacy review says otherwise.
• Track coverage. The console shows how many assessments are annotated. Aim to raise that percentage over time.

Besides general bot detection, the Enterprise service offers deeper features for specific problems. Availability and names can change, so check the current list.

Layers of defence

No single layer stops everything. Good defence stacks layers so that what slips past one is caught by the next. Bots are also adaptive. When you improve defences, attackers change tactics, so treat protection as an ongoing process.

An honest view of what you gain and what you give up.

The big trade-offs

Friction versus safety. More challenges stop more abuse and also annoy more people. Aim to challenge only the uncertain few.

Invisible versus visible checks. Invisible scoring gives the best experience and flexibility. Visible checkboxes give a clear moment of proof and a fallback for borderline cases.

Edge protection versus application logic. Protection at the firewall needs fewer code changes, but application-level checks know more about the action and can apply finer rules.

Privacy versus accuracy. More signals mean better detection, but also more data collection. Balance with transparency and legal advice.

Cost versus coverage. Protecting every page costs more than protecting only the critical actions. Start with the highest-risk steps.

A security tool must itself be used securely, or attackers will simply go around it.

Server-side checks are mandatory

• Always verify tokens on the server. Reject requests without a token or with an invalid one.
• Check the action and the hostname. A token for one action or site must not pass for another.
• Use each token once. Do not accept the same token twice.
• Check promptly. Tokens expire in minutes.
• Do not rely on the browser to tell you the score. Only the server’s own call to the service can be trusted.

Protect your credentials

The site key is public by design. The credentials that your server uses to create assessments are not. Use a service account or the platform’s built-in identity, with only the reCAPTCHA role it needs, and avoid long-lived keys in code or configuration files. If you must use an API key, restrict it to the reCAPTCHA service and to your server’s addresses, and store it in a secret manager.

Control access

• Use IAM roles carefully. Separate people who manage keys, people who only view reports, and programs that create assessments.
• Separate environments. Use different keys and projects for testing and production, and never use a test key to protect real traffic.
• Restrict domains. Keep the allowed-domain list exact.
• Audit. Turn on audit logs so key changes and setting updates are recorded.
• Plan for key replacement. If a key is abused, create a new one and move traffic across without long downtime.

Privacy and fairness

The service collects information about the browser, device, and behaviour to judge risk. You must tell users how this is used, follow the service terms, and meet laws in your region. Include proper wording in your privacy notice and any required consent mechanism. Also provide a path for honest users who are wrongly challenged or blocked, with clear help, accessible alternatives, and quick support. Some users rely on screen readers, special devices, or privacy tools, and may score lower. Test your flows with them and avoid hard blocks without an alternative.

Watching the scores tells you about both your attackers and your own health.

What to watch

• Score distribution by action. A healthy site shows most real traffic at high scores. A sudden growth in the low-score group suggests an attack.
• Volume spikes. A sharp jump in assessments for login or checkout may signal credential stuffing or carding.
• Challenge and block rates. If they rise sharply without an attack, your threshold or a site change may be harming real users.
• Reason codes. A growing share of one reason, such as automation, points to the attack type.
• Missing or invalid tokens. A rise suggests attackers bypassing the front end, or a bug in a new release.
• Annotation coverage. Higher coverage means better future accuracy.
• Latency and errors of assessment calls. Make sure the protection is not slowing checkouts.
• Business outcomes. Chargebacks, fake account counts, and support tickets for lockouts show the real impact.

Build an alert for the combination of a rising low-score share and a rising volume on a sensitive action. That pattern is the classic fingerprint of an automated attack, and early warning lets you tighten rules, add challenges, or contact your security team while the attack is still small.

Protection should be fast for users and sensible for your budget.

Performance points

• Load the script efficiently. Load it where it is needed, and make sure it does not block your page from showing.
• Request tokens at the moment of action. Fresh tokens are more accurate, and prevent expiry problems.
• Keep the server call lean. The assessment call adds a short delay. Make it once per action and handle failures gracefully.
• Set timeouts. Do not let a slow call freeze a checkout. Choose a clear fallback.
• Warm up on busy pages. For single-page apps, make sure tokens are created for each new action, not reused.

What you pay for

The service has historically been billed by the number of assessments, often with a free monthly allowance and a price per thousand beyond it. Extra features, such as account protection and payment fraud checks, may be priced separately. Prices and allowances change, so check the current pricing page.

Helpful habits and harmful habits seen again and again in real projects.

Helpful patterns

Anti-patterns to avoid

More things to steer clear of

• Creating the token once at page load. It will expire or be reused. Make it at the moment of action.
• Showing exact scores or reasons to users. It helps attackers tune their bots.
• Using the same key everywhere. You lose clean statistics and mix testing with production.
• Ignoring accessibility. Hard blocks without alternatives harm real people.
• Never annotating. You miss the biggest accuracy gains.
• Forgetting the outage plan. Decide how the application behaves if assessments fail.
• Relying on reCAPTCHA alone. Combine it with rate limits, strong passwords, and second factors.

A checklist of habits that experienced security teams rely on.

Habits that work

• List and rank your risky actions before you start.
• Use clear action names and check them on the server.
• Verify every token on the server, once, quickly.
• Start in observation mode and tune from real data.
• Use graded responses with step-up verification.
• Annotate outcomes and track coverage.
• Use separate keys for each environment and major use.
• Restrict domains and credentials.
• Combine layers: edge rules, scoring, account checks, and business rules.
• Test with real devices and assistive tools.
• Document your privacy use and keep notices up to date.
• Review dashboards weekly and after every campaign or release.

Mistakes beginners often make

Common ways teams use reCAPTCHA Enterprise. These are typical scenarios, not claims about any particular company.

reCAPTCHA Enterprise is one tool among several. Here is how it compares.

A simple rule of thumb: use rate limits and a firewall to stop floods, use reCAPTCHA Enterprise to judge each important action, use multi-factor authentication to protect accounts, and use human review and business rules for the gray cases. Together, they form layers that are much stronger than any one tool.