reCAPTCHA Enterprise is a Google Cloud service that tells you how likely it is that a visitor or an action is a real person and not a bot or a fraudster.

The problem it solves

Every public website attracts unwanted visitors. A bot is a program that acts like a person, only much faster and in huge numbers. Some bots are helpful, such as the crawlers that let search engines find your pages. Many are harmful: they create thousands of fake accounts, try stolen passwords on your login page, copy your product prices, post spam in comment boxes, or test stolen credit card numbers on your checkout. Fraud is the wider word for these dishonest uses of your service, and some of it is carried out by real humans, not just programs.

The old way to fight this was to show every visitor a puzzle, such as typing distorted letters. That annoyed real customers, was hard for people with disabilities, and modern programs learned to solve the puzzles anyway. A better approach is to judge visitors quietly in the background and ask for proof only when something looks suspicious.

What the service actually does

The service watches how a visitor interacts with your page or app and combines that with signals gathered from across the internet. When you ask, it returns a risk score, a number between zero and one that says how likely the visitor is to be a genuine person. A score near one means very likely human; a score near zero means very likely a bot. It also returns reason codes that explain why a score is low. Your own server then decides what to do: allow the action, ask for extra verification, slow the visitor down, or block them.

Beyond simple bot detection, the enterprise version adds protections for specific harms: account takeover, fake account creation, leaked passwords, text-message abuse, and payment fraud. It is a managed service, so there are no detection servers for you to run or tune from scratch.

reCAPTCHA Enterprise is one layer in a defence that also includes your network edge, your identity system and your monitoring tools.

reCAPTCHA Enterprise versus a firewall

A firewall looks at network traffic: addresses, request rates and patterns that match known attacks. It is excellent at blocking floods and known exploits. reCAPTCHA Enterprise looks at the visitor: is this a real person using a real browser or app, and does this action look natural? The two complement each other. A firewall can stop ten thousand identical requests per second, while reCAPTCHA Enterprise can notice that a slow, polite stream of requests from many addresses is actually one scripted attacker.

reCAPTCHA Enterprise versus your own rate limits

Rate limits cap how often one address or account may act. They are simple and useful, but attackers spread their traffic across thousands of addresses to stay under the cap. The risk score helps because it is based on behaviour and shared knowledge of attacks, not only on counting requests from one source.

flowchart LR
  V["Visitor"] --> E["Edge protection such as Cloud Armor"]
  E --> A["Your web app or mobile app"]
  A -->|"Execute with site key"| R["reCAPTCHA Enterprise"]
  R -->|"Token"| A
  A -->|"Token to your server"| S["Your backend"]
  S -->|"Create assessment"| R
  R -->|"Score and reasons"| S
  S --> D["Allow, challenge or block"]
        

A small set of words unlocks the whole service.

The type of key you create decides what the visitor sees and how the check runs.

Every integration starts with creating a key for your property. The key type is chosen at creation and shapes the whole experience. There are several families, and each has a clear job.

Score-based keys: the quiet default

Score-based keys are the most common choice. Your page asks the service to observe the visitor while they act, and gets back a token. Your server then asks for the score. Because the visitor sees no puzzle, the experience is smooth. You decide the thresholds and responses yourself, so this key type is the most flexible.

Checkbox keys: a visible gate

Checkbox keys show a small box that visitors click. Often a click is enough; when the service is unsure it may show an image puzzle. Choose this when you prefer a visible step, for example on a contact form that is flooded with spam and where one extra click is acceptable.

Mobile keys

Apps cannot run the web script, so there is a software kit for Android and iOS that gathers the app’s signals and returns a token in the same way. A mobile key is tied to the identity of your app, such as its package name or bundle identifier, so that tokens created by copycat apps are rejected.

Edge and firewall keys

Some keys are designed to work with a firewall or content delivery service. The edge component installs a special token on visitors and evaluates traffic before it reaches your servers. Google Cloud Armor offers a tight integration, and some third-party edge providers are supported as well. Check the current documentation for supported providers and features.

flowchart TD
  Q1{"Is the visitor using a mobile app?"}
  Q1 -->|Yes| M["Create a mobile key"]
  Q1 -->|No| Q2{"Do you want to judge traffic at the edge before your servers?"}
  Q2 -->|Yes| ED["Create an edge or firewall key"]
  Q2 -->|No| Q3{"Prefer an invisible check with full control over reactions?"}
  Q3 -->|Yes| SC["Create a score-based key"]
  Q3 -->|No| CB["Create a checkbox key"]
        

Four parties take part in every check: the visitor’s device, the service, your backend, and your decision logic.

Although reCAPTCHA Enterprise is fully managed, it helps to picture its parts. Each plays a distinct role, and errors usually come from misunderstanding who does what.

Why the backend call is non-negotiable

The token that reaches your server came through the visitor’s device, and an attacker controls that device. A token alone proves nothing until your server verifies it with the service. If your code skips this step, or trusts a client who says “I passed”, then attackers can simply claim success. The server-side assessment is the only trusted moment in the whole flow.

flowchart LR
  subgraph Client["Visitor side"]
    PG["Web page or mobile app"]
  end
  subgraph Google["Google Cloud"]
    RE["reCAPTCHA Enterprise"]
  end
  subgraph Yours["Your environment"]
    BE["Backend service"]
    DL["Decision rules"]
    FB["Feedback sender"]
  end
  PG -->|"Signals"| RE
  RE -->|"Token"| PG
  PG -->|"Request with token"| BE
  BE -->|"Assessment request"| RE
  RE -->|"Score and reasons"| BE
  BE --> DL
  DL --> FB
  FB -->|"Annotation"| RE
        

Follow a single login attempt through every step.

Let us trace a real example. A visitor opens your login page, types an email and password, and presses the button. Here is what happens behind the scenes.

sequenceDiagram
  participant U as Visitor
  participant P as Web page
  participant R as reCAPTCHA Enterprise
  participant S as Your server
  U->>P: Open login page
  P->>R: Load script with site key
  U->>P: Press sign in
  P->>R: Execute with action login
  R-->>P: Token
  P->>S: Credentials and token
  S->>R: Create assessment with token
  R-->>S: Validity, score, reasons
  S->>S: Apply decision rules
  S-->>P: Allow, challenge or deny
  S->>R: Later send annotation
        

Reading the reply correctly is the difference between real protection and a false sense of security.

The life of a token

A token is a short-lived code. It is valid for only a couple of minutes, and it can be assessed only once. If your server tries to use the same token a second time, or uses an expired token, the service reports it as invalid. This protects against attackers who record a good token and replay it later.

What comes back in an assessment

An assessment response has several parts, and a careful server reads all of them, not just the score.

Always check these four things

The score is a risk dial, and where you set the line decides how many customers you annoy and how many attackers you stop.

What a score means

Scores run from zero to one. One means the interaction looks very much like a genuine person, and zero means it looks very much like a bot. By default the service returns a small number of distinct score levels, and a finer-grained option exists for organisations that need more detail. Check the current documentation for what your chosen tier returns, because the number of levels affects how precisely you can tune.

Reason codes

A low score comes with reasons that explain the suspicion. These help you choose the right response and help your team investigate.

Choosing your thresholds

There is no perfect number for everyone. A common starting point is a middle value, and teams then tune from real traffic. A free-form comment box can tolerate a stricter line because a lost message costs little. A checkout form needs a gentler line combined with extra checks, because blocking a real customer costs money. Use the dashboard distribution of scores for your own traffic to see how many visitors fall into each range, and move the line gradually.

flowchart TD
  S["Assessment returned"] --> V{"Token valid and action matches?"}
  V -->|No| B1["Treat as suspicious and retry"]
  V -->|Yes| H{"Score high?"}
  H -->|Yes| A1["Allow the action"]
  H -->|No| M{"Score in the middle?"}
  M -->|Yes| C1["Add gentle extra verification"]
  M -->|No| B2["Block or slow down and log reasons"]
        

A challenge is a speed bump, not a wall, and it works best when it appears rarely.

Why challenges exist

Silent scoring is wonderful for real visitors, but when the service is unsure, you may want more proof before allowing a sensitive action. A challenge is a small test that a genuine person can pass quickly and that is costly or difficult for automated programs. Examples include a checkbox that evaluates the click itself, an image puzzle, or a second verification step that you build, such as a code sent to a verified email address or phone.

Types of extra proof

Accessibility and fairness

Puzzles are hard for many people, including those who use screen readers, have low vision, or cannot easily use a mouse. Heavy use of image challenges can lock out real customers and may create legal and reputational risk. Prefer silent scoring and light second factors, keep challenges for truly doubtful cases, and make sure an alternative path exists for those who struggle.

flowchart LR
  A["Low or middle score"] --> B{"How sensitive is the action?"}
  B -->|"Low sensitivity"| C["Silent allow with logging"]
  B -->|"Medium sensitivity"| D["Light challenge or short delay"]
  B -->|"High sensitivity"| E["Second factor or manual review"]
        

The service gets smarter about your site when you tell it what really happened.

An assessment is a prediction made at the moment of the action. The truth often becomes known later: a payment is charged back, a customer completes a second verification, a support team confirms a hijacked account. Annotation is the act of sending that truth back to the service, linked to the original assessment. This helps the service adapt to the patterns of your particular business.

What to report back

Timing of feedback

Some feedback can be sent immediately, such as the result of a password check, and some arrives days or weeks later, such as a payment dispute. Both are valuable. Keep the assessment identifier with your own records, for example stored with the order or the login attempt, so that you can find it when the truth arrives.

sequenceDiagram
  participant S as Your server
  participant R as reCAPTCHA Enterprise
  participant D as Your database
  participant F as Fraud or support team
  S->>R: Create assessment
  R-->>S: Score and assessment name
  S->>D: Store assessment name with order
  F->>D: Later confirm outcome
  D->>S: Outcome and stored name
  S->>R: Send annotation with legitimate or fraudulent
        

Bots are only one threat. The most costly attacks target the accounts of your real customers.

Two big account threats

Account takeover happens when an attacker gains control of a genuine customer’s account, often with a stolen password, then steals stored value, personal data or loyalty points. Fake account creation happens when attackers register large numbers of bogus accounts to abuse free trials, sign-up bonuses, reviews or messaging.

How it works in simple terms

Account Defender builds a profile of normal activity for each account, using an identifier that your site provides for the account. Privacy-minded setups use an identifier that is hashed or otherwise masked, so that the service does not need the real username. With that profile, a later login can be judged not only as “is this a bot?” but also as “is this the usual person for this account?”. It can also group accounts that look related, which is a useful clue for finding networks of fake accounts created by one attacker.

What your server must do

Attackers do not need to guess passwords when billions of real ones are already leaked.

The attack in plain words

When a website is breached, the stolen pairs of usernames and passwords end up for sale. Because many people reuse the same password on several sites, attackers take a leaked list and try each pair on other websites, a method called credential stuffing. A small fraction of tries succeed, and with millions of attempts that is plenty to cause damage. The login attempts look polite and use correct-looking details, so simple rate limits barely slow them.

How leak detection helps

Password leak detection lets you check whether a username and password pair the visitor just submitted appears in known collections of leaked credentials. The check is designed to protect privacy: it works with specially processed, one-way versions of the credentials so that the real values are not revealed to the service or to anyone else. If a match is found, you know that the pair is already in criminal hands, even if it is correct for your site.

flowchart TD
  L["Login attempt arrives"] --> A["Assess token and read score"]
  A --> B["Run private leaked credential check"]
  B --> C{"Pair found in leaked data?"}
  C -->|No| D{"Score acceptable?"}
  C -->|Yes| E["Require password reset or second factor"]
  D -->|Yes| F["Continue login"]
  D -->|No| G["Block or add extra verification"]
        

Other defences that work well together

Some attacks aim straight at your money: your messaging bill and your payment system.

SMS toll fraud

Many sites send a verification code by text message. Attackers abuse this by triggering thousands of messages to phone numbers they control or profit from, often in costly destinations. You pay for each message and the attacker receives a share of the fee. This is sometimes called SMS toll fraud or pumping. The visitor looks like a normal person requesting a code, and the damage appears as a surprising bill.

reCAPTCHA Enterprise offers protection for this scenario by assessing the phone number request together with the visitor, producing a signal about the chance that the phone number request is part of a pumping pattern. Your server uses that signal to decide whether to send the message. Check the current documentation for availability and exact response fields.

Card testing, also called carding

Criminals who steal card numbers do not know which are still active. They test them with tiny purchases or donations on websites that are easy to abuse. Merchants then face fees, chargebacks and damaged payment relationships. The reason code for suspected carding flags traffic that matches this pattern.

Payment fraud assessment

For merchants, Google offers payment-oriented risk assessment that scores a transaction using the information you share about it, such as the customer, the payment method and the order. This is a separate capability from simple bot detection and is typically used with more details about the transaction. Availability, inputs and pricing are specific to the offering, so confirm them in the current documentation.

Judge traffic at the front gate, before it reaches your application at all.

Instead of calling the service from every page of your code, you can place reCAPTCHA Enterprise at your network edge. With a supported firewall or content delivery service, visitors receive a special session token, a longer-lived token that represents the visitor’s browsing session. The edge evaluates the session token and applies rules that you define, for example allowing, blocking, redirecting to a challenge page, or limiting the rate of traffic with a poor reputation.

Two kinds of tokens

Benefits of the edge approach

flowchart LR
  V["Visitor"] --> E["Edge firewall with reCAPTCHA rules"]
  E -->|"Good session token"| A["Your application"]
  E -->|"Missing or poor token"| C["Challenge page or block"]
  A -->|"Sensitive actions"| R["Server-side assessment"]
        

Phones and tablets need the same watchful guard, with different equipment.

Mobile apps are attacked in the same ways as websites: fake accounts, credential stuffing and scraping through the app’s hidden interfaces. Because apps cannot run the web script, reCAPTCHA Enterprise provides a software kit for Android and iOS. The app asks the kit for a token at the moment of the action, sends it to your backend, and the backend creates an assessment exactly as it does for web traffic.

Special points for mobile

A calm, ordered path from an empty project to a protected login.

Setup is straightforward when you follow a sensible order. Think of it like installing a new alarm system in a shop: you decide where the sensors go, test them, and agree what to do when an alarm sounds, before you rely on it.

The protection tool must itself be protected.

Who can do what

Access is managed through Identity and Access Management, using predefined roles for common jobs.

Protecting the server-side call

A tool that watches behaviour carries a duty to be open about it.

To judge whether a visitor is a real person, the service collects signals about how they interact with your page or app and about their device and environment. That is what makes it effective, and it also means you are responsible for handling the topic honestly. Privacy rules differ between countries, industries and platforms, so always take advice from your own legal and privacy specialists. The points below are general guidance, not legal advice.

What good practice looks like

The badge and the notice

For invisible keys, a small badge normally appears on the page. The terms allow you to hide it only if you replace it with a visible notice that tells users the site is protected and that the provider’s privacy policy and terms apply. Read the current terms carefully before changing the look of your page.

Fairness and accessibility

Automated risk decisions can wrongly affect real people, especially those using privacy tools, shared networks or assistive technology. Offer a clear, humane route to resolve mistakes, such as a support contact or an alternative verification, and watch for patterns where certain groups are unfairly blocked more often.

Attackers adapt, so protection is a habit, not a one-time installation.

What the console shows

The Google Cloud console presents statistics for each key, including how many requests arrive, how scores are distributed, how many tokens were invalid, and, where relevant, how challenges were solved. These views help you see whether a sudden surge is organic, such as a marketing campaign, or hostile, such as a bot wave at three in the morning.

Add your own business signals

The service sees traffic, but you see consequences. Track how many sign-ups are confirmed, how many orders are disputed, how many password resets succeed, how many text messages you send and what they cost. Compare these with the scores to learn whether your thresholds match real outcomes. Cloud Logging and Cloud Monitoring are the natural home for your own decision logs and alerts.

flowchart LR
  AS["Assessments and scores"] --> LG["Your decision logs"]
  LG --> DB["Dashboard"]
  LG --> AL["Alerts"]
  BO["Business outcomes such as disputes"] --> DB
  DB --> RV["Monthly review"]
  AL --> OC["On-call responder"]
  RV --> TH["Adjust thresholds and rules"]
  TH --> AS
        

The service is inexpensive for many sites, but design choices change both the bill and the speed.

How charges usually work

Pricing is based mainly on the number of assessments you create, often with a monthly free allowance and a price per thousand assessments beyond it. Extra capabilities, such as account protection, payment fraud analysis and finer score detail, can carry their own charges or sit in higher tiers, and large organisations can negotiate commitments. Always read the current pricing page for exact figures, because they change.

Quotas and limits

Like most cloud services, the interface has limits on how many requests you can make per minute. Normal sites rarely reach them, but a flood of attack traffic or a very large launch might. Review the current limits, ask for increases ahead of big events, and design your server to cope with temporary errors using short, gradually lengthening retries.

Performance and user experience

Asking for a token adds a small delay, and the server-side assessment adds another round trip. These are usually short, but they matter on slow mobile connections and for checkout flows. Good habits include loading the script early and asynchronously so it does not delay the page, requesting the token just before the action, calling the assessment interface from a server close to Google’s service, and keeping the decision logic fast and simple.

Good protection comes from a handful of repeatable habits.

flowchart TD
  V["Visitor"] --> L1["Layer 1: Edge rules and session token"]
  L1 --> L2["Layer 2: Server-side assessment with action check"]
  L2 --> L3["Layer 3: Account signals and leaked credential check"]
  L3 --> L4["Layer 4: Second factor for risky cases"]
  L4 --> OK["Action allowed"]
  L1 -.-> X["Block early"]
  L2 -.-> X
  L3 -.-> X
  L4 -.-> X
        

These habits quietly weaken protection or hurt real customers.

A checklist in plain words that any team can adopt.

Common mistakes beginners make

The same service protects very different businesses. These scenarios show how.

flowchart LR
  RT["Retail checkout"] --> RE["reCAPTCHA Enterprise"]
  BK["Bank login"] --> RE
  TK["Ticket sign-up"] --> RE
  ST["Streaming trial"] --> RE
  MS["Text message codes"] --> RE
  RE --> DEC["Each business applies its own rules"]
        

An honest comparison always includes the limits.

How the options compare

When something looks wrong, work from the visitor toward your decision, one link at a time.

flowchart TD
  A["Many real users blocked or all tokens invalid"] --> B{"Is the script or kit loading on the page or app?"}
  B -->|No| C["Fix loading, content rules and network blocks"]
  B -->|Yes| D{"Does the key match the domain or app identifier?"}
  D -->|No| E["Correct key restrictions"]
  D -->|Yes| F{"Is the token requested right before the action and sent once?"}
  F -->|No| G["Request a fresh token at submit time"]
  F -->|Yes| H{"Does the action name match on page and server?"}
  H -->|No| I["Align the action names"]
  H -->|Yes| J{"Is the server using the right project and permissions?"}
  J -->|No| K["Fix service identity and role"]
  J -->|Yes| L["Review thresholds, reasons and recent changes"]
        

Symptom: every assessment says the token is invalid

The usual causes are expired tokens, tokens used twice, a key that does not match the domain, or a server using the wrong project. Check that the page asks for the token just before submission, that the token is sent once, and that the server is calling the same project and key as the page.

Symptom: real customers keep getting low scores

Look at the reason codes. Common causes include unusual browser setups, corporate networks that share one address, privacy tools, or a script that loads late so the service sees little behaviour. Load the script earlier, widen coverage across pages, and move the middle range to a gentle challenge instead of a block.

Symptom: bots still get through

Check whether every entry point is protected, whether tokens are actually verified on the server, whether the action name is checked, and whether thresholds are too lenient for the action. Review blocked and allowed samples and add edge rules for obvious automation.

Symptom: permission errors from the server

The service identity may lack the agent role, or may belong to a different project. Grant the narrow role to the correct identity, and confirm which project the call targets.

Symptom: sudden bill increase

Look for attack traffic hitting protected forms, loops in your own code that assess repeatedly, or assessments on every page view where only key actions need them. Reduce unneeded calls and add edge filtering.

Preparation turns a frightening surge into a managed event.

Sooner or later a wave of abusive traffic arrives: thousands of fake sign-ups overnight, a burst of login attempts, or a sudden stream of tiny card payments. A short written playbook helps the team act calmly instead of guessing.

sequenceDiagram
  participant M as Monitoring
  participant T as On-call team
  participant R as Rules and thresholds
  participant S as Support
  M->>T: Alert on unusual traffic or cost
  T->>T: Identify the targeted action
  T->>R: Tighten controls for that action
  T->>S: Prepare path for wrongly blocked users
  R-->>M: Effect visible in metrics
  T->>R: Relax gradually after the wave
  T->>T: Review and improve playbook
        

Introduce protection carefully, prove that it works, and grow it in stages.

The riskiest moment of any protection project is the first launch, because mistakes there either let attackers through or block real customers. A calm testing and rollout plan removes most of that risk. Think of it like opening a new road: you test it with a few cars first, watch the traffic, and only then open all lanes.

What to test before launch

A gentle rollout plan

flowchart LR
  ST["Staging tests"] --> OB["Observation mode in production"]
  OB --> AN["Analyse score distribution"]
  AN --> G["Gentle response on one action"]
  G --> EX["Expand to more actions"]
  EX --> OP["Operate, monitor and retune"]
  OP -.->|"Learn and adjust"| AN
        

Moving from older reCAPTCHA versions

Many sites begin with the older, simpler reCAPTCHA products and later move to the enterprise service for its richer scoring, reason codes and specialised protections. The idea is the same, a site key on the page and a server-side check, but the enterprise service uses an assessment interface and offers more detail. Plan the move as a normal rollout: create new keys, integrate in staging, run in observation mode, then switch traffic across. Check the current migration guidance in the documentation, because details and timelines can change.

A maturity path

The site key is a public identifier of your website or app, placed in your page. A token is a short-lived, single-use code created for one visitor action, which your server verifies through an assessment.

No. With score-based keys the check is invisible. Visible challenges are shown only if you choose a checkbox key or trigger an extra check for doubtful cases.

It is a number from zero to one. Higher means the interaction looks more like a real person, and lower means it looks more like a bot. It is a probability, so combine it with reason codes and business context.

The browser or app is under the visitor’s control. Only a server-side assessment with protected credentials gives a trusted result that cannot be forged by an attacker.

Tokens are valid for a short time, about two minutes, and can be assessed only once. Ask for a fresh token right before the action. Check current documentation for the exact lifetime.

An action is a label for what the visitor is doing, such as login or checkout. Naming it lets the service judge in context and lets your server detect tokens reused on a different page.

It is optional but valuable. Sending annotations about confirmed fraud or confirmed legitimate users helps the service adapt to your business and improves accuracy over time.

Yes. Android and iOS software kits create tokens inside the app, which your backend verifies in the same way as web tokens, using a key tied to your app’s identity.

It is an attack that tries leaked username and password pairs on other sites. Scoring helps spot automated attempts, and leaked credential checks tell you when a submitted pair is known to be exposed so you can require a reset or second factor.

No. A firewall blocks known attack patterns and floods, while reCAPTCHA Enterprise judges whether a visitor behaves like a real person. They work best together.

The service uses behaviour and device signals, so you should disclose its use in your privacy notice, collect only what you need, and follow the rules of the regions you serve. Take advice from your legal team.

Decide in advance per action. Low-risk actions may proceed with extra monitoring, while high-risk actions such as payments should be delayed or denied until protection is available.

For many sites the cost is modest, often with a free monthly allowance and a price per thousand assessments beyond it. Extra features may cost more. Check the current pricing page.

reCAPTCHA Enterprise is the watchful, mostly invisible guard of your website and mobile app. It observes how visitors behave, issues a short-lived token, and, when your server asks, returns a risk score with reason codes. Your server verifies every token, checks its validity and action, and turns the score into a proportional response: allow, add a gentle check, slow down or block. Beyond bot detection, the service offers focused protection against account takeover, fake accounts, leaked passwords, text message abuse and payment fraud, and it can work at the network edge through firewall integration. Success depends on good habits: protecting every sensitive entry point, starting in observation mode, matching friction to risk, closing the feedback loop, respecting privacy and accessibility, monitoring continuously, and keeping a calm playbook for the day an attack arrives.