SCA e 3D Secure sui rinnovi degli abbonamenti: gestire authentication_required

La maggior parte dei rinnovi falliti riguarda soldi o carte: fondi insufficienti, una carta scaduta, un blocco della banca. Un tipo è diverso. La carta va bene e i soldi ci sono, ma la banca vuole che il cliente confermi il pagamento. Su Stripe, questo si presenta come il decline code authentication_required, o come una fattura in attesa di un’azione del cliente.

Nessun nuovo tentativo lo risolve. Il cliente deve tornare e approvare il pagamento. Questa guida spiega perché succede, cosa fa Stripe per te e come far superare il passaggio al cliente in fretta. Si basa sulla documentazione di Stripe e sulle regole europee che ci stanno dietro (fonti consultate a novembre 2026).

Questa non è una consulenza legale. La regolamentazione dei pagamenti è complessa; verifica la tua configurazione con Stripe e, se serve, con uno specialista.

Perché i rinnovi richiedono un’autenticazione

La Strong Customer Authentication in breve

La Strong Customer Authentication (SCA) deriva dalla seconda direttiva europea sui servizi di pagamento (PSD2). Richiede a chi paga di autenticare i pagamenti elettronici con due fattori su tre: qualcosa che sa, qualcosa che ha, qualcosa che è. Per le carte, il modo abituale di farlo online è 3D Secure, in cui la banca mostra un passaggio di conferma (un codice, un’approvazione nell’app, un’impronta digitale).

Secondo la guida alla SCA e il centro assistenza di Stripe, la SCA si applica quando sia il provider di pagamento dell’azienda sia la banca del titolare della carta si trovano nello Spazio economico europeo. La pagina sulle esenzioni di Stripe copre anche Regno Unito e Svizzera. I pagamenti in cui una delle due parti è fuori dalla regione («one leg out») sono esclusi, anche se le banche possono comunque chiedere un’autenticazione.

Pagamenti ricorrenti e transazioni avviate dal merchant

Un rinnovo di abbonamento avviene quando il cliente non è presente. Le regole ne tengono conto:

• Le norme tecniche dell’UE, il Regolamento delegato (UE) 2018/389 della Commissione, richiedono la SCA quando chi paga crea, modifica o avvia per la prima volta una serie di operazioni ricorrenti con lo stesso importo e lo stesso beneficiario. I pagamenti successivi della serie possono essere esenti (articolo 14).
• I pagamenti con carta che il merchant avvia in base a un accordo con il cliente sono trattati come transazioni avviate dal merchant (MIT). La pagina sulle esenzioni di Stripe spiega che la carta va autenticata quando viene salvata, e che ti serve l’accordo del cliente (un mandato) per addebitarla in seguito. Segnare un pagamento come MIT funziona in modo simile a chiedere un’esenzione.

Quindi, in linea di principio, un’autenticazione all’iscrizione copre i rinnovi futuri.

Perché fallisce lo stesso

In pratica, l’ultima parola spetta alla banca emittente. Può rifiutare un’esenzione o una MIT e chiedere comunque l’autenticazione. Le situazioni comuni includono una variazione dell’importo (un upgrade, un aumento di prezzo, addebiti a consumo), una carta salvata senza autenticazione, o semplicemente la valutazione del rischio della banca stessa. Quando succede su un rinnovo off-session, nessuno è lì per completare 3D Secure, e il pagamento fallisce.

L’articolo di supporto di Stripe sui rifiuti authentication_required aggiunge un caso limite: a volte gli emittenti restituiscono authentication_required anche su pagamenti che hanno già superato 3D Secure. In quel caso, il cliente deve contattare la sua banca.

Cosa fa Stripe per gli abbonamenti

Se usi Stripe Billing, Stripe gestisce gran parte del meccanismo:

• I rinnovi sono segnati come off-session in automatico. L’articolo di Stripe su on-session e off-session dice che questo flag viene impostato per te sui rinnovi Billing.
• Le carte salvate diventano MIT. Secondo la pagina di Stripe sulla preparazione alla SCA, quando una carta viene salvata tramite le API Payment Intents o Setup Intents, i pagamenti off-session successivi vengono segnati come avviati dal merchant.
• La fattura ti dice quando serve un’azione. Stripe invia l’evento invoice.payment_action_required quando il pagamento di una fattura richiede un’ulteriore azione del cliente. La guida di Stripe ai webhook degli abbonamenti dice che a quel punto la tua app deve avvisare il cliente.
• La pagina della fattura hosted gestisce 3D Secure. La hosted invoice page può eseguire il flusso di autenticazione senza lavoro in più da parte tua.
• Stripe può inviare l’email. Nelle impostazioni delle email ai clienti, puoi far inviare a Stripe un link con cui i clienti confermano i pagamenti quando la loro banca lo richiede.

Sui nuovi tentativi, nota che la pagina Smart Retries di Stripe elenca authentication_required tra gli hard decline code: Stripe non lo ritenterà in automatico senza un’azione del cliente.

I due modi in cui si presenta

Segnale	Cosa significa	Cosa fare
invoice.payment_action_required, PaymentIntent in requires_action	La banca vuole 3D Secure per questo pagamento	Invia al cliente il link della fattura hosted (o della tua pagina) per confermare
Decline code authentication_required su invoice.payment_failed	L’emittente ha rifiutato e ha chiesto un’autenticazione	Uguale: riporta il cliente on-session per confermare o reinserire la carta

L’articolo di supporto di Stripe sui fallimenti SCA off-session segnala che un PaymentIntent off-session fallito può finire in requires_payment_method invece che in requires_action. Se costruisci la tua pagina di conferma, gestisci entrambi gli stati: o confermi il metodo di pagamento esistente con 3D Secure, o raccogli di nuovo un metodo di pagamento.

Far confermare il cliente

Il cliente non ha fatto nulla di sbagliato, e spesso non sa cosa significhi «autenticazione». Il messaggio deve essere breve, calmo e preciso.

Cosa deve dire l’email

• Oggetto: «Conferma il tuo pagamento [Prodotto]»
• Perché: «La tua banca ti chiede di confermare questo pagamento. È un normale controllo di sicurezza, non un problema con la tua carta.»
• Cosa: l’importo, il piano, la data.
• Come: un solo pulsante, «Conferma pagamento», che porta dritto alla pagina di conferma.
• Quando: «Il tuo abbonamento resta attivo mentre confermi. Se non riusciamo a confermare entro il [data], verrà sospeso.»

Evita «il tuo pagamento non è andato a buon fine» nell’oggetto. Non è del tutto vero, e fa pensare ai clienti di aver bisogno di una nuova carta.

Tempistica

Invia il primo messaggio appena arriva l’evento. A differenza dei soft decline, aspettare non serve: la banca non cambierà idea da sola. Basta un breve richiamo dopo due o tre giorni, poi un avviso finale prima della fine del tuo periodo di tolleranza. I nostri modelli di email di sollecito includono una variante per l’autenticazione.

La pagina di conferma

• Funziona su mobile senza login (un link firmato).
• Mostra l’importo e il prodotto prima del passaggio con la banca.
• Apre direttamente il passaggio 3D Secure della banca.
• Offre «usa un’altra carta» come alternativa, per i clienti la cui banca continua a rifiutare.
• Conferma chiaramente il successo, e ferma tutte le email successive su invoice.paid.

Ridurre i fallimenti di autenticazione

Non puoi eliminarli del tutto, perché decide la banca. Puoi renderli più rari.

1. Autentica quando la carta viene salvata

Raccogli la carta con un SetupIntent (o il primo PaymentIntent) e setup_future_usage impostato per l’uso off-session, così la carta è autenticata con il mandato in vigore. La documentazione SetupIntents di Stripe lo spiega. Stripe Checkout e il Payment Element lo fanno per te all’iscrizione all’abbonamento.

2. Raccogli di nuovo quando cambi l’accordo

Upgrade, cambi di prezzo e nuovi add-on cambiano l’importo. Dove possibile, fai confermare la modifica al cliente mentre è nella tua app, così qualsiasi autenticazione avviene on-session invece che alle 3 di notte del giorno del rinnovo.

3. Attenzione alle prove gratuite

Se una prova parte senza addebito, assicurati che la carta sia comunque salvata tramite un SetupIntent con autenticazione. Altrimenti il primo addebito vero, dopo la prova, è la prima volta che la banca vede il mandato. Parliamo delle prove in conversione da prova a pagamento.

4. Gestisci l’India a parte

L’India ha le sue regole sui pagamenti ricorrenti. La pagina di Stripe sui pagamenti ricorrenti in India spiega che le carte richiedono un e-mandate registrato con autenticazione a fattore aggiuntivo, che i clienti ricevono una notifica pre-addebito almeno 24 ore prima di ogni addebito, e che gli addebiti ricorrenti sopra 15.000 INR richiedono l’autenticazione ogni volta. Se hai clienti indiani, leggi quella pagina; funziona in modo diverso dalla SCA.

Misurarlo

Segui l’autenticazione separatamente dagli altri fallimenti. Si comporta in modo diverso e ha la sua soluzione.

• Richieste di autenticazione al mese, per paese della carta.
• Tasso di conferma: fatture con una richiesta di autenticazione pagate entro il tuo periodo di tolleranza.
• Tempo di conferma: dall’evento a invoice.paid.
• Tasso di ripiego: clienti che hanno confermato passando invece a una nuova carta.

Se il tasso di conferma è basso, guarda prima l’email (oggetto, chiarezza, un solo pulsante), poi la pagina su mobile.

Checklist

• Le carte vengono salvate con autenticazione off-session all’iscrizione.
• invoice.payment_action_required e authentication_required fanno partire entrambi un’email di conferma.
• Le email «confirm payment» di Stripe sono attive, o le tue email le sostituiscono (non entrambe).
• La pagina di conferma funziona su mobile senza password.
• Cambi di prezzo e upgrade vengono confermati on-session dove possibile.
• Le email si fermano appena la fattura è pagata.
• L’autenticazione è riportata come categoria a sé.
• I clienti indiani sono gestiti secondo le regole dell’e-mandate.

Come aiuta NoChurn

NoChurn tratta le richieste di autenticazione come un caso a sé. Quando un rinnovo richiede una conferma, salta i nuovi tentativi inutili e invia un’email di recupero scritta dall’IA, controllata prima dell’invio e nella lingua del cliente, che spiega che la banca vuole una conferma rapida, con un link per confermare il pagamento e una pagina hosted di aggiornamento della carta come alternativa. I dati della carta restano in Stripe.

Si collega a Stripe in un clic, o funziona via API con la tua fatturazione. Il prezzo dipende solo dall’MRR, mai dai ricavi recuperati. Vedi pagamenti falliti e prezzi.