Adding a CAPTCHA to a form looks like a 30-minute task: drop in the script tag, paste the API key, submit a token with the form. It is a 30-minute task. It's also where most teams ship a verification that's either trivially bypassable or quietly broken in production.

This post walks through the integration mistakes that show up in real codebases — and the patterns that avoid them.

The four common failure modes

Mistake 1: Validating only on the client.

You drop the widget on the form, listen for the "verified" callback, and submit the form. The CAPTCHA token comes back, you trust it, the user proceeds.

The problem: the token never reaches your backend for validation. An attacker opens DevTools, deletes the widget, fakes the success callback, and submits. You have no way to know.

The fix: the token must be sent to your backend, and your backend must call the CAPTCHA vendor's verification endpoint to confirm it before accepting the form. Client-side success is just a UX hint.

Mistake 2: Reusing tokens.

A user signs up. Your backend validates the token. The user closes the page, comes back, signs up again with the same email. Your backend hits a duplicate-email error and returns it to the form, which still has the old token cached. The user retries. Your backend re-validates the token — and it succeeds because some implementations don't enforce single-use.

The fix: the verification endpoint should be single-use. CaptchaLa enforces this server-side, but if your vendor doesn't, you need to track consumed tokens yourself in Redis or your DB.

Mistake 3: Validating without action binding.

You add CAPTCHA to your signup form. Then you add it to your login form. You're using the same token-validation function for both, just calling the same endpoint. An attacker grabs a token from the public signup page (no auth needed) and replays it against the login endpoint to bypass account-takeover protection.

The fix: bind the token to the action it was issued for. The verification request should include action: 'signup' or action: 'login', and the validation response should include the action. Reject if mismatched.

Mistake 4: Mounting the widget too late.

A modern CAPTCHA collects behavioral signals from the moment the widget loads. If you mount it inside a modal that opens when the user clicks "Sign up," the widget has zero seconds of trajectory data and almost no entropy. The risk score is poor, the user gets a harder challenge, and conversion drops.

The fix: mount the widget on initial page load, not on form-open. Let it collect data while the user is reading the page. By the time they click "Sign up," there's enough behavioral signal for a clean verification.

A correct integration outline

1. Page loads → CAPTCHA widget mounts immediately
2. User reads page, fills form (widget collects signals throughout)
3. User clicks "Submit" → widget produces a token bound to action and submits with form
4. Backend receives form + token
5. Backend POSTs to /api/v1/challenge/verify with token + action + user IP
6. Vendor returns valid: true/false (and a fresh risk score)
7. If valid, backend processes form and consumes token (single-use)
8. If invalid, backend returns specific error code so frontend can reset and retry

That's the whole flow. Most teams skip step 5 because the client already returned "verified," but step 5 is where the real security lives. Steps 1–4 are UX; step 5 is verification.

What good error handling looks like

A user who fails verification should never see "Error" with no context. Common cases worth handling:

• Token expired. Refresh the widget, ask user to retry.
• Token already consumed. Reset and re-issue. Usually a double-submit.
• Action mismatch. Log it; this is almost always a code bug, not user error.
• High-risk score, escalation required. Let the widget show a heavier challenge and re-emit a new token.
• Backend can't reach verification API. Fail closed for high-value actions (payments), fail open for low-value (analytics signup). Don't lock everyone out if the API is briefly down.

How CaptchaLa handles the server side

CaptchaLa's verification endpoint is a single POST: token in, structured response out. The response includes the validation result, the risk score, the action it was bound to, and a flag for whether the verification was offline (meaning the token was generated locally without server reachability). Your backend gets enough information to make a real decision, not just a yes/no.

The server SDK ships for PHP, Node.js, Go, and Python. Single-use enforcement is built in — replaying a consumed token returns consumed: true rather than silently succeeding. Documentation is at https://captcha.la/docs.

The takeaway

Most CAPTCHA integration bugs are subtle. The widget appears to work, the form submits, the verification "passes" — and your fraud rate doesn't go down. The fix is treating the client-side widget as UX and the server-side validation as security. They serve different purposes, and skipping the second one is how teams ship CAPTCHAs that don't actually defend anything.

A 30-minute integration is fine. Just spend 25 of those minutes on the server side.