Cải thiện UX reCAPTCHA v3 cho người dùng thật

Phạm vi an toàn: Áp dụng cho môi trường QA, staging hoặc pre-production do bạn sở hữu hoặc được uỷ quyền — không dành cho hệ thống bên thứ ba.

Người dùng thật hiếm khi bị reCAPTCHA v3 chặn vì "trông giống bot" — thường do action đặt tên sai, ngưỡng dùng chung một giá trị cho mọi luồng, hoặc ứng dụng thiếu phương án dự phòng khi điểm thấp. v3 chỉ trả về một điểm 0.0–1.0, không hiện challenge trực quan — cách bạn xử lý con điểm đó quyết định trải nghiệm hơn thuật toán của Google.

Ba việc cần sửa trước khi đổ lỗi cho reCAPTCHA

1. Đặt tên action theo đúng luồng nghiệp vụ, không dùng tên chung chung.
2. Chia ngưỡng riêng theo từng luồng thay vì một con số dùng cho toàn ứng dụng.
3. Dựng phương án dự phòng khi điểm thấp, rồi xác thực cả luồng trong QA trước khi lên production.

Đặt tên action theo đúng chức năng

Google tính điểm dựa một phần trên action khai báo khi gọi grecaptcha.execute. Đặt tên theo luồng nghiệp vụ — login, signup, checkout — thay vì một tên chung như submit cho mọi form. Tên action phải khớp giữa client và backend xác thực token; lệch tên khiến backend từ chối token hợp lệ, dễ nhầm thành "reCAPTCHA chặn nhầm".

Chia ngưỡng theo luồng, tránh một con số dùng chung

Một ngưỡng chặn 0.5 áp cho toàn ứng dụng gần như luôn sai ở đâu đó: luồng đăng nhập quen thuộc thường đạt điểm cao hơn hẳn checkout khách vãng lai — đặt ngưỡng theo rủi ro thực tế từng luồng.

Một đội QA outsourcing tại TP.HCM từng gặp đúng lỗi này: ngưỡng 0.5 áp chung cho cả trang đăng nhập lẫn form dùng thử công khai, khiến khách lần đầu bị yêu cầu xác minh thêm dù hành vi bình thường. Tách ngưỡng theo action và ghi log riêng từng luồng một tuần trên staging mới chốt được con số phù hợp.

Dựng phương án dự phòng khi điểm thấp

Khi điểm dưới ngưỡng, đừng từ chối thẳng — đưa người dùng sang v2 dạng checkbox hoặc một bước xác minh bổ sung (mã gửi email). Từ chối cứng ngay dễ biến người dùng thật dùng mạng công ty thành đơn bỏ dở.

Xác thực bằng CaptchaAI trong QA

Tái tạo cấu hình production trong staging, rồi dùng CaptchaAI đi hết luồng: lấy token, gửi backend, kích hoạt fallback — không cần chờ traffic thật tự sinh ca điểm thấp. Gói BASIC ($15/tháng, 5 thread) đủ cho một đội nhỏ chạy song song vài kịch bản/ngày. Đoạn Python dưới đây minh hoạ luồng tối thiểu: gửi task rồi polling kết quả.

import os
import requests

API_KEY = os.environ['CAPTCHAAI_KEY']
QA_PAGE_URL = os.environ['QA_PAGE_URL']  # ví dụ https://staging.example.com/qa-login
QA_SITE_KEY = os.environ['QA_SITE_KEY']


def submit_qa_recaptcha() -> str:
    payload = {
        'clientKey': API_KEY,
        'task': {
            'type': 'NoCaptchaTaskProxyless',
            'websiteURL': QA_PAGE_URL,
            'websiteKey': QA_SITE_KEY,
        },
    }
    response = requests.post(
        'https://api.captchaai.com/createTask',
        json=payload,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()['taskId']


def fetch_qa_result(task_id: str) -> dict:
    payload = {'clientKey': API_KEY, 'taskId': task_id}
    response = requests.post(
        'https://api.captchaai.com/getTaskResult',
        json=payload,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()

Khắc phục sự cố thường gặp

Ghi log rồi chốt danh mục kiểm tra trước khi triển khai

Ghi log có cấu trúc cho mỗi lần chạy QA: thời gian lấy token, mã trạng thái HTTP, ID task, độ sâu hàng đợi. Nối các bước bằng một correlation id (OpenTelemetry) để cắt giảm thời gian chẩn đoán. Trước khi triển khai, đối chiếu danh mục sau:

• Phạm vi kiểm thử giới hạn trong tài nguyên đã uỷ quyền.
• Khoá CaptchaAI nằm trong CI secret hoặc vault, không trong mã nguồn.
• Mỗi lần chạy ghi lại thời gian gọi và mã trạng thái.
• Có chính sách thử lại idempotent, giới hạn cho lỗi tạm thời.
• Bài kiểm thử tái lập trên CI, không cần thủ công.

Câu hỏi thường gặp

reCAPTCHA v3 có luôn trả cùng một điểm cho cùng người dùng không?

Không. Điểm tính lại mỗi lần gọi theo hành vi và bối cảnh phiên — đừng thiết kế logic dựa trên điểm cố định.

Nên đặt ngưỡng chặn ở mức bao nhiêu?

Không có con số đúng cho mọi ứng dụng: thấp cho luồng rủi ro thấp, cao hơn cho checkout vãng lai, rồi tinh chỉnh theo log thực tế.

Nên xử lý lỗi tạm thời như thế nào?

Thử lại idempotent kèm exponential backoff (1s, 2s, 4s) và một giới hạn trên. Lỗi mạng, mã 5xx, ERROR_NO_SLOT_AVAILABLE nên thử lại; lỗi xác thực kéo dài thì không.

Hướng dẫn liên quan an toàn

• Bắt đầu nhanh CaptchaAI
• Kiểm thử QA được uỷ quyền
• Kiểm thử endpoint trên form
• Trình duyệt fail, API pass
• Giải reCAPTCHA v2 qua API
• Giải Turnstile qua API
• Giải GeeTest v3 qua API

Kiểm thử luồng reCAPTCHA v3 với CaptchaAI trong môi trường nội bộ của bạn.