SMS two-factor authentication feels like a security feature, but the message itself is a billable event. Attackers abuse that gap with SMS pumping and toll fraud: they trigger verification messages to premium, high-cost, or attacker-controlled number ranges until the victim pays the messaging bill.
A normal CAPTCHA score is not enough by itself because the expensive decision happens before the user proves they own the phone. reCAPTCHA SMS defense focuses on that exact point. The backend creates an assessment with the phone number, reads the SMS toll fraud risk, and decides whether to send, step up, rate limit, or block before the SMS provider is called.
The score is inverted compared with the global score
Teams often trip on the meaning of the SMS defense score. Google describes the SMS toll fraud risk value as low near 0.0 and high near 1.0. That is the opposite direction many engineers remember from the normal reCAPTCHA global score, where higher is usually more legitimate.
Write that distinction into code comments, dashboards, and runbooks. A threshold named blockBelow from a normal CAPTCHA implementation can become dangerous if copied into an SMS toll fraud check. Prefer explicit names such as smsTollFraudRisk, reviewAtOrAbove, and blockAtOrAbove.
Check before sending the code
The risk decision belongs in the pre-send path. A good flow collects the phone number, generates the reCAPTCHA token for the action, creates the assessment from the backend, reads phoneFraudAssessment.smsTollFraudVerdict.risk, and only then calls the SMS provider if the policy allows it.
Do not make the SMS vendor call first and evaluate the risk later. That turns fraud detection into a reporting feature rather than a control. Also avoid retry storms: if the same phone number, IP range, device, or account hits the risk threshold repeatedly, slow the flow down and preserve the evidence for review.
Handle phone data carefully
For the SMS defense assessment, Google requires the phone number in E.164 format and says it should not be hashed or encrypted in that field. That does not mean you should log it everywhere. Keep application logs redacted, restrict access to raw phone numbers, and store only what you need for fraud review and legal retention.
If your system uses an account identifier, keep it stable and site-specific. For accounts without an internal ID, use the same opaque identifier discipline you would use for Account Defender. The goal is to give the model enough continuity without spraying user identity across logs, support tools, and analytics exports.
Annotate outcomes quickly
SMS defense is stronger when the system sends feedback after the event. Google documents annotation reasons such as an initiated two-factor message, a passed two-factor check, and a failed two-factor check. Those annotations should happen within minutes, not as a loose weekly cleanup job.
For a production flow, wire annotations near the same code that records verification status. If the code was sent, annotate the initiated event. If the user enters the correct code, annotate the passed event. If the user fails, annotate the failed event. Keep idempotency around assessment IDs so retries do not create noisy duplicate feedback.
Where rCAPTCHA fits
rCAPTCHA can reduce challenge friction on the public forms that lead into phone verification, especially when repeated visual puzzles are causing abandonment. SMS toll fraud still needs a phone-aware backend decision. Treat rCAPTCHA as one layer in a practical funnel: block obvious automation, score phone risk before sending, rate limit expensive paths, and preserve a recovery route for legitimate users.
The best result is not "no one suspicious ever receives an SMS." The best result is fewer expensive sends to high-risk numbers, fewer support tickets from legitimate users, and a dashboard that shows which actions, countries, routes, and campaigns are driving cost.
Sources and further reading
Google Cloud SMS fraud detection documentation for SMS defense assessments, risk direction, E.164 phone numbers, and annotations.
Account Defender accountId guide for stable account identifiers and safe logging.
Action-name planning for login, signup, MFA, and phone update flows.
Try rCAPTCHA on your own site
Start with a minimal free testing plan, add a real site key, and see per-site verification data before moving to a paid tier.