Como avisar os clientes de um pagamento falhado no Intercom

Quando uma renovação falha, o cliente normalmente não sabe. Descobre quando o acesso para, ou quando um email de recuperação cai no separador de promoções. Se já usa o Intercom para falar com os clientes dentro do seu produto, ele pode levar a mensagem do pagamento falhado ao sítio onde o cliente realmente está: a app.

Este guia mostra o que o Intercom consegue fazer com os dados de falhas de pagamento, como configurar uma mensagem na app e como tratar as conversas de suporte que se seguem. Baseia-se no centro de ajuda do Intercom sobre a app Stripe, as mensagens acionadas por eventos, os banners e as macros, e na referência da Data Events API (todos consultados em novembro de 2026).

O Intercom não faz novas tentativas de pagamento

Comece pelo que o Intercom não é. Não cobra cartões, não faz novas tentativas de pagamento nem atualiza métodos de pagamento. Isso fica com o seu sistema de faturação: no Stripe, as novas tentativas vêm das Smart Retries ou do seu próprio calendário, e a atualização do cartão acontece numa página alojada pelo Stripe ou na sua app. O papel do Intercom é a comunicação: avisar o cliente, no momento certo, com um link que resolve o problema. Para o lado da faturação, veja como recuperar pagamentos falhados no Stripe.

Pôr os dados de falhas de pagamento no Intercom

Opção 1: a app Stripe

A app Stripe do Intercom importa os dados dos clientes Stripe como atributos dos utilizadores do Intercom. Entre os atributos documentados:

Atributo	O que contém
stripe_delinquent	O estado de incumprimento no Stripe (true ou false)
stripe_subscription_status	O estado da subscrição
stripe_card_expires_at	Quando expira o cartão guardado
stripe_card_brand	A marca do cartão

A app também envia eventos para o Intercom, incluindo charge_failed, charged, invoice_created e deleted_subscription. Restrições do mesmo artigo: só os dados do modo live são sincronizados (o modo de teste não é suportado), a app exige uma conta Stripe paga e está disponível nos planos Essential, Advanced e Expert do Intercom. Por omissão, um utilizador Intercom só é criado a partir de um cliente Stripe quando o cliente Stripe tem um email e um ID de utilizador nos seus metadados.

Opção 2: enviar o seu próprio evento

Se não está no Stripe, ou quer mais controlo, envie você mesmo um evento quando o seu sistema de faturação reporta uma falha. A Data Events API recebe um POST em /events com um event_name, um timestamp Unix created_at, um identificador do utilizador (user_id ou email) e metadata opcionais. JSON aninhado não é suportado nos metadados, e a documentação da API limita o número de chaves de metadados acompanhadas por evento, por isso mantenha-os planos e curtos: por exemplo, um montante, um ID de fatura e o URL da página de atualização do cartão.

Um evento personalizado permite-lhe dar-lhe um nome claro (payment_failed) e levar o link de atualização consigo, o que os eventos da app Stripe não fazem por si.

Escolher o tipo de mensagem

Banners: visíveis até o problema estar resolvido

Um banner fica no topo da página. Se esconder o botão para fechar, o Intercom continua a mostrá-lo até o utilizador deixar de cumprir as regras de público ou concluir a ação configurada. Isso serve bem um pagamento falhado: dirija-o aos utilizadores em que stripe_delinquent é true (ou o seu próprio atributo), e o banner desaparece sozinho quando o pagamento passa e o atributo volta atrás.

Limites da documentação do Intercom:

• Os banners só suportam públicos dinâmicos.
• Só são entregues quando o utilizador é visto online no Messenger.
• Não funcionam de forma nativa nas apps iOS ou Android.
• Se vários banners se sobrepõem, aparecem pela ordem em que foram ativados, e um banner que não se pode fechar colocado primeiro bloqueia os seguintes.

Chats ou posts acionados por eventos: uma vez por falha

Para enviar uma mensagem sempre que acontece uma falha, use uma mensagem acionada por evento. O Intercom documenta várias condições:

• Exige o add-on Proactive Support Plus.
• A mensagem tem de usar um público dinâmico, e só pode acrescentar uma regra baseada em eventos.
• Os eventos ocorridos antes de a mensagem ser ativada não a acionam.
• Se o evento chegar fora do horário da mensagem, a mensagem não é enviada para esse evento; não fica retida até o horário abrir.
• Os metadados do evento não podem ser usados em mensagens dentro de uma Series. O Intercom sugere criar primeiro a mensagem isolada e depois copiá-la para a Series.

Email: continua a ser necessário

As mensagens na app só chegam aos clientes que iniciam sessão. Um cliente que deixou de usar o produto precisa de um email, e é muitas vezes esse o que mais importa. Mantenha uma sequência de emails de recuperação a funcionar a partir do seu sistema de faturação ou de uma ferramenta dedicada. Tem exemplos prontos em modelos de emails de recuperação.

Escrever a mensagem

A mensagem na app deve ser curta e concreta:

O seu último pagamento não foi aceite. Atualize o seu método de pagamento para manter o seu plano [nome do plano] ativo. [Atualizar método de pagamento]

Regras a seguir:

1. Uma ação. Um único botão para a página de atualização do cartão. Não envie os clientes para uma página de definições genérica.
2. Sem culpa, sem motivo. Não mostre o motivo da recusa. Para alguns códigos, como cartões perdidos ou roubados, o Stripe diz para apresentar a recusa como genérica; veja os códigos de recusa do Stripe explicados.
3. Diga o que acontece a seguir, com honestidade: quando vai tentar de novo, ou quando o acesso vai mudar. Não invente um prazo que não vai aplicar.
4. Mostre-a à pessoa certa. Nos produtos B2B, quem vê o banner pode não ser quem paga. Dirija-o aos administradores ou aos contactos de faturação se tiver esse atributo.

Tratar as respostas

As mensagens de pagamento falhado geram conversas: “Atualizei o cartão, porque continua a falhar?”, “Posso pagar por transferência bancária?”, “Cancelem e pronto.” Prepare macros para cada uma. As ações das macros podem adicionar tags e atribuir a uma equipa, por isso marque estas conversas com payment-failed para medir o volume.

Antes de responder, consulte o painel da app Stripe, que mostra as subscrições do cliente e os três pagamentos mais recentes ao lado da conversa. Algumas situações comuns:

O cliente diz	Verificar	Resposta
“Atualizei o cartão”	Foi associado um novo método de pagamento, e a fatura voltou a ser tentada?	Se ainda não foi, explique quando; ou volte a tentar a partir do seu sistema de faturação
“O meu banco diz que está tudo bem”	O código de recusa	Para recusas genéricas, sugira outro cartão ou voltar a ligar ao banco
“Cancelem e pronto”	Se é mesmo isso que quer	Cancele se confirmar; um pagamento falhado não é razão para dificultar o cancelamento
“Fui cobrado duas vezes”	Histórico de pagamentos	Explique ou reembolse depressa; é assim que começam as disputas

Erros comuns

• Usar o banner como único canal. Os clientes que não iniciam sessão nunca o veem.
• Deixar o banner depois da recuperação. Use um atributo que volta atrás automaticamente, não uma lista manual.
• Testar com o modo de teste do Stripe. A app Stripe ignora os dados de teste, por isso teste antes com um evento personalizado num utilizador de teste.
• Enviar uma mensagem durante uma nova tentativa que está prestes a resultar. Se o seu sistema de faturação volta a tentar em poucas horas para algumas recusas, esperar um pouco antes da primeira mensagem pode evitar alarmes desnecessários.

Fazer isto com a NoChurn

A NoChurn trata do lado da faturação que o Intercom não trata: novas tentativas inteligentes programadas segundo o motivo da recusa e os dias de pagamento prováveis, emails de recuperação escritos por IA que revê, e uma página alojada de atualização do cartão para a qual pode remeter a partir de um banner ou de uma macro do Intercom. O seu conector Intercom é só de leitura, por isso não envia mensagens do Intercom por si; os seus banners e macros ficam no Intercom. Lê as conversas, associadas aos clientes pelo email (correspondências duvidosas sugeridas, nunca fundidas automaticamente), e usa-as no churn score. Veja NoChurn + Intercom.