Descritores de faturação: a prevenção de chargebacks mais barata

Um cliente olha para o extrato do cartão, vê uma linha que não reconhece e toca em “contestar” na app do banco. O banco regista-a como fraude. Para um negócio de subscrições, esta é uma das formas mais comuns de uma cobrança perfeitamente válida se tornar um chargeback, e a solução não custa nada: mudar o texto dessa linha.

Esse texto é o statement descriptor (também chamado billing descriptor ou soft descriptor). Este guia explica o que é, as regras no Stripe e no Braintree, como escrever um bom descritor para subscrições e o que mais ajuda os clientes a reconhecer uma cobrança. Fontes: do Stripe, statement descriptors, what is a statement descriptor, why customers see descriptors that don’t match e a checklist de conta; do Braintree, descriptors e a referência Transaction: Sale; e a revised enhanced descriptor policy da Visa (todos consultados em novembro de 2026).

Porque é que os descritores causam disputas

O descritor é muitas vezes a única informação que um cliente tem sobre uma cobrança quando olha para o extrato. Três situações geram disputas do tipo “não reconheço isto”:

1. O descritor mostra a entidade jurídica, não a marca. “ACME HOLDINGS LTD” não diz nada a quem subscreveu o “Planwise”.
2. Uma empresa, vários produtos. Se tem três apps numa só conta e todas as cobranças mostram o mesmo nome, os clientes não conseguem perceber que subscrição estão a pagar.
3. A cobrança chega muito depois da inscrição. Uma renovação anual chega onze meses depois de o cliente ter pensado em si pela última vez. Um nome claro é o único lembrete.

Estas disputas chegam normalmente como fraude (Visa 10.4, Mastercard 4863 “o titular do cartão não reconhece”). Mesmo que as ganhe, contam para os seus rácios de disputas das redes. Preveni-las é muito mais barato.

As regras no Stripe

A documentação de statement descriptors do Stripe fixa estes limites para pagamentos com cartão:

Regra	Limite
Comprimento total	5 a 22 caracteres
Caracteres	Apenas caracteres latinos; pelo menos uma letra
Caracteres proibidos	Parênteses angulares, aspas simples e duplas, e o asterisco
Conteúdo	Tem de refletir o nome comercial (DBA), o URL ou a denominação legal; não pode ser só números

Prefixo e sufixo dinâmico

O Stripe permite combinar um prefixo estático (chamado shortened descriptor no Dashboard) com um sufixo dinâmico por pagamento:

• O prefixo tem 2 a 10 caracteres.
• O Stripe junta prefixo e sufixo com um asterisco e um espaço, e esse separador conta para os 22 caracteres. Com um prefixo de 7 caracteres, sobram 13 caracteres para o sufixo.
• Os sufixos dinâmicos só funcionam para pagamentos com cartão.
• Só os primeiros 22 caracteres são enviados para pagamentos com cartão; o que for mais longo é cortado.

Para subscrições, é no sufixo que coloca o produto ou o plano: PLANWISE* PRO ANNUAL.

O que o cliente vê realmente

O artigo de suporte do Stripe sobre descritores que não correspondem explica que alguns bancos mostram um nome de comerciante “amigável” em vez do seu descritor, usando vários dados da transação, e que o Stripe não tem controlo sobre essa associação. A checklist de conta do Stripe acrescenta que os emissores podem também mostrar outra informação da conta, como o nome da empresa, a morada, o email ou o telefone. Verifique se os dados públicos da sua empresa na conta do processador (telefone de suporte, URL de suporte) são dados que aceita que os clientes vejam, e se funcionam.

As regras no Braintree

O Braintree suporta dynamic descriptors por transação, mas não estão ativos por predefinição em todas as contas. A sua referência Transaction: Sale descreve o formato do nome:

Parte da empresa	Parte do produto	Total com asterisco
3 caracteres	até 18	22
7 caracteres	até 14	22
12 caracteres	até 9	22

O Braintree documenta também um campo de telefone e um de URL para os descritores, e nota que o comprimento exato e as regras de caracteres dependem do seu processador, e que alguns processadores aceitam um URL enquanto outros só aceitam um número de telefone. Verifique as definições da sua conta antes de contar com um formato.

Como é um bom descritor de subscrição

Princípios

1. Comece pelo nome que os clientes conhecem. A marca da sua app, dos seus emails e do ícone da app, não a holding.
2. Acrescente o produto ou o plano quando tiver espaço. Sobretudo se vende mais do que um produto ou tem planos mensais e anuais.
3. Mantenha-o legível. Evite abreviaturas que ninguém adivinharia.
4. Seja consistente. Use o mesmo descritor nos lembretes, recibos e artigos da central de ajuda, para que um cliente que o pesquise o encontre a si.

Exemplos

Fraco	Melhor	Porquê
ACME HOLDINGS LTD	PLANWISE* PRO MONTHLY	Marca e plano em vez da entidade jurídica
AHL*SUB 88213	PLANWISE* TEAM ANNUAL	Sem códigos internos
PLANWISE	PLANWISE* RENEWAL	Indica uma cobrança recorrente
WWW.PLNWS.IO	PLANWISE.COM	Um domínio que o cliente consegue escrever

Confirme que cada exemplo cumpre as regras de caracteres do seu processador; o asterisco nestes exemplos é o separador do Stripe, não um caractere que escreve no prefixo.

Períodos de teste

Quando um teste gratuito passa a pago, a primeira cobrança é a que mais provavelmente surpreende. A Visa chegou a exigir um descritor melhorado para essa primeira cobrança depois de um teste; a sua política revista (dezembro de 2020) tornou-o opcional. Mesmo sendo opcional, um sufixo como TRIAL END ou FIRST CHARGE nesse pagamento ajuda, se o seu processador permitir definir um sufixo por pagamento. As regras da Visa para testes continuam a exigir um lembrete com um link de cancelamento pelo menos sete dias antes dessa cobrança.

Diga aos clientes o que vão ver

O descritor funciona melhor quando o cliente já o viu antes. Coloque-o:

• Na página de checkout: “Isto vai aparecer no seu extrato como PLANWISE* PRO.”
• No email de boas-vindas e em todos os recibos.
• Nos lembretes de renovação e de fim do período de teste. Veja lembretes de renovação de planos anuais.
• Num artigo da central de ajuda com o próprio descritor no título, para que um cliente que pesquise “PLANWISE PRO cobrança” o encontre.

As boas práticas de prevenção de fraude do Stripe também recomendam dizer aos clientes, no seu site, o que vão ver no extrato.

Verifique como fica

Não presuma. Faça uma compra real com o seu próprio cartão para cada produto e plano, e depois veja:

• a transação pendente na app do seu banco;
• a transação lançada alguns dias depois;
• o extrato mensal.

Os bancos e as apps mostram os descritores de formas diferentes, e alguns substituem-nos por um nome amigável. Se o que vê não for o que definiu, contacte o seu processador.

Meça o efeito

Depois de mudar o descritor, compare nos meses seguintes:

• a proporção de disputas com códigos de motivo “não reconhecido” ou fraude em clientes existentes;
• os pedidos de suporte a perguntar “que cobrança é esta?”;
• as inquiries e retrievals (nas redes que ainda os usam).

As disputas chegam semanas depois da cobrança, por isso dê-lhe pelo menos dois ciclos de faturação antes de avaliar.

Checklist do descritor

• Nome da marca que os clientes conhecem, não a entidade jurídica.
• Sufixo com produto ou plano onde for suportado.
• Dentro das regras de comprimento e de caracteres do seu processador.
• Telefone e URL de suporte públicos definidos e a funcionar.
• Descritor mostrado no checkout, nos recibos e lembretes, e na central de ajuda.
• Testado num cartão real.
• Descritor separado por produto, se vende vários.

Para o resto do plano de prevenção, veja como prevenir chargebacks em subscrições.

Fazer isto com o NoChurn

O NoChurn não define o seu descritor; isso fica no Stripe ou no Braintree. O que faz é mostrar cada disputa com o seu motivo, para que possa ver se as disputas por “não reconhecido” e por fraude descem depois de o mudar, e reunir provas automaticamente quando uma disputa chega na mesma (respostas do fluxo de cancelamento, emails enviados, utilização que envia por API, conversas do helpdesk só em leitura), com uma resposta redigida pela IA que uma pessoa revê antes de ser enviada. Veja chargebacks.