Come avvisare i clienti di un pagamento fallito in Intercom

Quando un rinnovo fallisce, il cliente di solito non lo sa. Lo scopre quando l’accesso si interrompe, o quando un’email di sollecito finisce nella scheda promozioni. Se usi già Intercom per parlare con i clienti dentro il tuo prodotto, può portare il messaggio sul pagamento fallito nel posto in cui il cliente si trova davvero: l’app.

Questa guida mostra cosa può fare Intercom con i dati sui pagamenti falliti, come impostare un messaggio in-app e come gestire le conversazioni di supporto che ne seguono. Si basa sul centro assistenza di Intercom per l’app Stripe, i messaggi basati su eventi, i banner e le macro, e sul riferimento della Data Events API (tutti consultati a novembre 2026).

Intercom non ritenta i pagamenti

Parti da ciò che Intercom non è. Non addebita carte, non ritenta pagamenti e non aggiorna metodi di pagamento. Tutto questo resta al tuo sistema di fatturazione: su Stripe, i tentativi vengono da Smart Retries o dal tuo calendario, e l’aggiornamento della carta avviene su una pagina ospitata da Stripe o nella tua app. Il ruolo di Intercom è la comunicazione: avvisare il cliente, al momento giusto, con un link che risolve il problema. Per il lato fatturazione, vedi come recuperare i pagamenti falliti su Stripe.

Portare i dati sui pagamenti falliti in Intercom

Opzione 1: l’app Stripe

L’app Stripe di Intercom importa i dati dei clienti Stripe come attributi sugli utenti Intercom. Tra gli attributi documentati:

Attributo	Cosa contiene
stripe_delinquent	Lo stato di morosità di Stripe (true o false)
stripe_subscription_status	Lo stato dell’abbonamento
stripe_card_expires_at	Quando scade la carta salvata
stripe_card_brand	Il circuito della carta

L’app invia anche eventi a Intercom, tra cui charge_failed, charged, invoice_created e deleted_subscription. Vincoli dallo stesso articolo: si sincronizzano solo i dati in modalità live (la modalità test non è supportata), l’app richiede un account Stripe a pagamento ed è disponibile sui piani Essential, Advanced ed Expert di Intercom. Di default, un utente Intercom viene creato da un cliente Stripe solo quando il cliente Stripe ha sia un’email sia un ID utente nei suoi metadati.

Opzione 2: inviare un tuo evento

Se non usi Stripe, o vuoi più controllo, invia tu un evento quando il tuo sistema di fatturazione segnala un fallimento. La Data Events API accetta un POST su /events con un event_name, un timestamp Unix created_at, un identificativo dell’utente (user_id o email) e metadata facoltativi. Il JSON annidato non è supportato nei metadati, e la documentazione dell’API limita il numero di chiavi di metadati tracciate per evento, quindi tienili piatti e ridotti: per esempio un importo, un ID fattura e l’URL della pagina di aggiornamento della carta.

Un evento personalizzato ti permette di dargli un nome chiaro (payment_failed) e di portare con sé il link di aggiornamento, cosa che gli eventi dell’app Stripe non fanno per te.

Scegliere il tipo di messaggio

Banner: visibili finché il problema non è risolto

Un banner sta in cima alla pagina. Se nascondi il pulsante di chiusura, Intercom continua a mostrarlo finché l’utente non smette di corrispondere alle regole del pubblico o non completa l’azione configurata. Si adatta bene a un pagamento fallito: punta agli utenti in cui stripe_delinquent è true (o un tuo attributo), e il banner sparisce da solo quando il pagamento va a buon fine e l’attributo torna indietro.

Limiti dalla documentazione di Intercom:

• I banner supportano solo pubblici dinamici.
• Vengono consegnati solo quando l’utente risulta online nel Messenger.
• Non funzionano in modo nativo nelle app iOS o Android.
• Se più banner si sovrappongono, vengono mostrati nell’ordine in cui sono stati attivati, e un banner non chiudibile posizionato per primo blocca quelli successivi.

Chat o post basati su eventi: uno per ogni fallimento

Per inviare un messaggio ogni volta che si verifica un fallimento, usa un messaggio basato su eventi. Intercom documenta diverse condizioni:

• Richiede l’add-on Proactive Support Plus.
• Il messaggio deve usare un pubblico dinamico, e puoi aggiungere una sola regola basata su eventi.
• Gli eventi avvenuti prima che il messaggio fosse attivato non lo fanno partire.
• Se l’evento arriva fuori dalla programmazione del messaggio, il messaggio non viene inviato per quell’evento; non viene trattenuto fino all’apertura della programmazione.
• I metadati degli eventi non si possono usare nei messaggi all’interno di una Series. Intercom suggerisce di costruire prima il messaggio da solo, poi copiarlo nella Series.

Email: ancora necessaria

I messaggi in-app raggiungono solo i clienti che accedono. Un cliente che ha smesso di usare il prodotto ha bisogno di un’email, ed è spesso quello che conta di più. Mantieni attiva una sequenza di email di sollecito dal tuo sistema di fatturazione o da uno strumento dedicato. Esempi pronti nei modelli di email di sollecito.

Scrivere il messaggio

Il messaggio in-app deve essere breve e specifico:

Il tuo ultimo pagamento non è andato a buon fine. Aggiorna il metodo di pagamento per mantenere attivo il tuo piano [nome del piano]. [Aggiorna il metodo di pagamento]

Regole da seguire:

1. Un’azione. Un solo pulsante verso la pagina di aggiornamento della carta. Non mandare i clienti a una pagina di impostazioni generica.
2. Nessuna colpa, nessun motivo. Non mostrare il motivo del rifiuto. Per alcuni codici, come le carte smarrite o rubate, Stripe ti dice di presentare il rifiuto come generico; vedi i codici di rifiuto di Stripe spiegati.
3. Di’ cosa succede dopo, con onestà: quando riproverai, o quando cambierà l’accesso. Non inventare una scadenza che non farai rispettare.
4. Mostralo alla persona giusta. Nei prodotti B2B, chi vede il banner può non essere chi paga. Punta agli amministratori o ai contatti di fatturazione se hai quell’attributo.

Gestire le risposte

I messaggi sui pagamenti falliti generano conversazioni: “ho aggiornato la carta, perché fallisce ancora?”, “posso pagare con bonifico?”, “disdite e basta.” Prepara delle macro per ciascuna. Le azioni delle macro possono aggiungere tag e assegnare a un team, quindi tagga queste conversazioni payment-failed per misurarne il volume.

Prima di rispondere, controlla il pannello dell’app Stripe, che mostra gli abbonamenti del cliente e i tre pagamenti più recenti accanto alla conversazione. Alcune situazioni comuni:

Il cliente dice	Controlla	Risposta
“Ho aggiornato la carta”	È stato collegato un nuovo metodo di pagamento, e la fattura è stata ritentata?	Se non è ancora stata ritentata, spiega quando; oppure ritenta dal tuo sistema di fatturazione
“La mia banca dice che è tutto a posto”	Il codice di rifiuto	Per i rifiuti generici, suggerisci un’altra carta o di richiamare la banca
“Disdite e basta”	Se lo intende davvero	Disdici se lo conferma; un pagamento fallito non è un motivo per rendere più difficile la disdetta
“Mi avete addebitato due volte”	Storico dei pagamenti	Spiega o rimborsa subito; è così che iniziano le contestazioni

Errori comuni

• Usare il banner come unico canale. I clienti che non accedono non lo vedono mai.
• Lasciare il banner dopo il recupero. Usa un attributo che torna indietro da solo, non un elenco manuale.
• Fare test con la modalità test di Stripe. L’app Stripe ignora i dati di test, quindi fai i test con un evento personalizzato su un utente di prova.
• Inviare messaggi durante un tentativo che sta per riuscire. Se il tuo sistema di fatturazione ritenta entro poche ore per alcuni rifiuti, un ritardo prima del primo messaggio può evitare allarmi inutili.

Farlo con NoChurn

NoChurn gestisce il lato fatturazione che Intercom non copre: tentativi intelligenti calibrati sul motivo del rifiuto e sui probabili giorni di paga, email di recupero scritte dall’IA che rivedi tu e una pagina ospitata di aggiornamento della carta a cui puoi rimandare da un banner o da una macro di Intercom. Il suo connettore Intercom è in sola lettura, quindi non invia messaggi Intercom al posto tuo; i tuoi banner e le tue macro restano in Intercom. Legge le conversazioni, associate ai clienti tramite email (le associazioni dubbie vengono proposte, mai unite automaticamente), e le usa nel churn score. Vedi NoChurn + Intercom.