Verificação por OTP: cinco coisas que ninguém conta antes de você integrar
Segmento não é mensagem, "enviado" não é "entregue" e um formulário de OTP aberto é um convite para inflar a sua fatura. O que a documentação costuma omitir.
Integrar verificação por código é fácil: dois endpoints, um manda e o outro confere. O que surpreende vem depois — na fatura, no relatório de entrega e, eventualmente, num ataque que ninguém tinha previsto.
Estas cinco coisas não costumam estar na primeira página da documentação de ninguém. Valem para qualquer fornecedor, não só para nós.
1. Você paga por segmento, não por mensagem
Um SMS cabe em 160 caracteres. Com qualquer acento, emoji ou caractere fora do alfabeto GSM básico, a mensagem inteira muda de codificação e o limite cai para 70.
Isso significa que uma mensagem em português já nasce mais cara em potencial: "Seu código de verificação é 123456" cabe em um segmento, mas um texto personalizado de 71 caracteres com um único "ç" custa dois — o dobro, para o usuário final ler a mesma coisa.
Nove caracteres contam em dobro mesmo no alfabeto básico: ^ { } \ [ ~ ] | e o
símbolo do euro.
O que fazer: conte os segmentos do texto renderizado, não do template. Um template de 60 caracteres com uma variável de 15 vira 75 — e dois segmentos.
2. "Enviado" não é "entregue", e a diferença é sua
Quase toda API devolve sucesso quando a operadora aceita a mensagem. Aceitar não é entregar. Entre um e outro há número inexistente, aparelho desligado, bloqueio de operadora e chip cancelado.
A diferença é grande o bastante para ser vista: numa base nossa de números brasileiros, 902 números com 12 dígitos — celulares antigos, sem o nono dígito — falharam em 100% das tentativas, em todos os gateways. O número não existe mais na numeração da Anatel, mas o envio é aceito e cobrado.
O que fazer: trate o estado de entrega como um campo separado do estado do
seu fluxo. Uma mensagem pode estar verificada (o usuário digitou o código) e
nunca ter sido confirmada como entregue — e pode estar enviada há dez minutos
sem nunca chegar. Se a sua API oferece webhook de entrega, ligue.
E o detalhe que dói: mensagem não entregue costuma ser cobrada. As operadoras não reembolsam, e nenhum intermediário absorve isso.
3. O preço muda por país — e muda muito
Não existe "preço do SMS". Existe preço por destino, e a variação é de mais de dez vezes entre os extremos: os destinos mais caros da nossa tabela custam mais de dez vezes o preço de um SMS para o Brasil.
Se o seu produto atende só o Brasil, isso é irrelevante. Se o seu formulário de cadastro aceita qualquer DDI, é a base do próximo item.
4. Formulário de OTP aberto é um vetor de fraude
Este é o que quase ninguém menciona, e é o mais caro.
O ataque chama-se AIT — tráfego artificialmente inflado. Funciona assim: um fraudador com acordo de receita junto a uma operadora de um país caro encontra o seu formulário de cadastro, e dispara milhares de solicitações de OTP para números daquele destino. Ele fatura a parte dele da terminação; você recebe a conta inteira.
Não é hipótese distante: é a razão pela qual empresas grandes limitam os destinos aceitos no cadastro. Os alvos típicos são justamente os destinos de tarifa alta, que quase nunca coincidem com o público real de um produto brasileiro.
O que fazer, em ordem de eficácia:
- Restrinja os destinos que o seu formulário aceita ao que o seu produto realmente atende. É a única medida que fecha o vetor em vez de encarecê-lo.
- Teto de gasto por conta e por dia, com alerta. Não impede o ataque, mas limita o estrago à janela de um dia.
- Cooldown por número — nós aplicamos 60 segundos por padrão. Ajuda contra o descuidado e contra o robô ingênuo, mas quem rotaciona números passa por cima.
- Captcha antes do envio, se o formulário for público de verdade.
Repare que a ordem importa: cooldown e captcha são o que todo mundo faz primeiro, e são os que menos protegem contra AIT.
5. O idioma da mensagem provavelmente não é o que você espera
Se a sua API escolhe o idioma sozinha quando você não informa, ela costuma escolher pelo país do número, não pela sua preferência. Um +595 recebe em espanhol, um +1 em inglês — mesmo que o seu produto seja inteiramente em português e o usuário more no Brasil.
O que fazer: mande o idioma explicitamente, sempre. É um campo, e a alternativa é descobrir pelo suporte.
E o WhatsApp?
Vale a comparação, porque o contrato costuma ser o mesmo e o custo não.
| SMS | WhatsApp (canal oficial) | |
|---|---|---|
| alcance | qualquer celular | quem tem WhatsApp |
| texto | seu | template aprovado pela Meta |
| cobrança | por segmento, por país | por requisição, + a Meta cobra você |
| entrega | estado por webhook | estado por webhook |
O ponto de atenção do WhatsApp oficial é que existem duas cobranças: a do intermediário e a da Meta, que cobra diretamente na sua conta Business pela conversa de autenticação. Um custo por verificação que parece menor pode não ser, depois de somar as duas.
E o texto não é seu: é o template de autenticação aprovado. O campo de idioma escolhe qual versão aprovada vai, não o conteúdo.
Em resumo
| item | o que assumir |
|---|---|
| custo | por segmento, e acento derruba o limite para 70 |
| entrega | "enviado" ≠ "entregue"; não entregue é cobrado |
| destino | preço varia mais de 10× entre países |
| fraude | restrinja destinos antes de tudo |
| idioma | mande explícito, sempre |
Nada disso é motivo para não usar OTP — continua sendo a verificação de telefone mais simples que existe. É motivo para integrar sabendo onde a conta cresce.