DevPortalPagoPA


Tabella dei contenuti

Prima del lancio

Questa checklist riassume i punti chiave delle linee guida UX per garantire un'implementazione corretta ed efficace del servizio RTP sui canali digitali di un PSP.

Brand e comunicazione

Terminologia e naming

  • L'acronimo "RTP" (o "Request to Pay") è stato evitato nell'interfaccia utente finale?
  • Si utilizzano le diciture corrette come "Richieste di pagamento", "Avvisi pagoPA" o "Pagamenti pagoPA"?
  • Si è evitato l'uso di termini errati o fuorvianti come "Bollettini pagoPA" o "CBILL"?
  • Il nome "pagoPA" è scritto correttamente (minuscolo, tranne la "PA" finale)?

Comunicazione e testi del servizio

  • I benefici chiave (es. avvisi pre-compilati, zero errori, promemoria scadenze) sono comunicati chiaramente?
  • Si rassicura l'utente che la banca/PSP agisce come intermediario sicuro per le richieste inviate dagli Enti tramite pagoPA?
  • È stato specificato che il servizio di ricezione è gratuito?
  • Vengono forniti esempi concreti dei tipi di avvisi che l'utente potrà ricevere (es. TARI, Bollo auto)?
  • Punto Chiave: Si rassicura esplicitamente l'utente che, aderendo al servizio, continuerà comunque a ricevere le comunicazioni su altri canali (es. App IO, posta)?
  • Nella promozione, si fa leva sulla sicurezza del canale bancario come antidoto a truffe e phishing?

Esperienza utente

Architettura e integrazione con il resto dell'app

  • Il servizio RTP è integrato nell'eventuale sezione "pagamenti pagoPA" già esistente nell'home-banking?
  • Si è evitata la creazione di una sezione separata dedicata solo a RTP?
  • La sezione "pagamenti pagoPA" funge da punto di riferimento completo, includendo le nuove richieste, lo storico dei pagamenti e le ricevute?
  • L'architettura dell'informazione raggruppa RTP come una modalità per pagare gli avvisi pagoPA, insieme al QR code e alla compilazione manuale?

Flusso di notifica

  • Si utilizzano più canali (es. push, in-app, email) per notificare la richiesta?
  • Notifiche Push:
    • Il titolo specifica lo scopo (es. "Hai ricevuto una richiesta di pagamento")?
    • Il corpo della notifica include l'ente e l'oggetto (es. "Comune di Ipazia - Tari 2025")?
    • Si è evitato di mostrare solo l'importo, che può generare ansia?
    • Si è evitato di usare "pagoPA" come mittente della notifica?
  • Notifiche Email:
    • L'email è personalizzata (es. "Ciao ") per ridurre il rischio phishing?
    • L'oggetto è chiaro e istituzionale (es. "Richiesta di pagamento da parte di [Ente]")?
    • Il tono di voce è professionale, evitando urgenza (es. "PAGA ORA")?
    • L'email contiene una CTA chiara che rimanda all'home-banking per visualizzare e pagare la richiesta (e non link di pagamento diretti)?
    • L'email non contiene allegati?

Schermata dettaglio richiesta di pagamento

  • La schermata include tutti gli elementi minimi richiesti?
    • Nome Ente creditore (completo e riconoscibile)
    • Oggetto del pagamento (chiaro, es. "TARI 2025 Prima rata")
    • Scadenza (e stato, es. "Pagabile fino al...")
    • Importo totale (le commissioni del PSP vanno mostrate solo nello step successivo)
    • Codice Avviso (18 cifre)
    • Codice Fiscale Ente creditore (11 cifre)
  • Le azioni (CTA) sono dinamiche e dipendono dallo stato della richiesta (es. "Procedi al pagamento" vs. "Visualizza la ricevuta")?
  • È presente un'indicazione chiara che, per dubbi sul contenuto (es. importo errato), l'utente deve contattare l'Ente Creditore (e non il PSP o pagoPA)?

Gestione Stati e Flusso di Pagamento

  • Disclaimer Importo: Prima del pagamento, l'utente viene avvisato che l'importo potrebbe subire variazioni (per sanzioni, interessi, sgravi, ecc.)?
  • Conferma Pagamento:
    • L'utente riceve un feedback immediato a schermo sull'esito del pagamento?
    • Lo stato della richiesta viene aggiornato automaticamente in "Pagata"?
    • Viene inviata una conferma su un altro canale (es. email)?
  • Ricevute:
    • Dalla richiesta "Pagata" è possibile accedere facilmente alla ricevuta?
    • Esiste una sezione nell'architettura dove recuperare tutte le ricevute pagoPA?
  • Gestione Stati: L'interfaccia gestisce visivamente tutti i seguenti stati?
    • Da pagare (con CTA di pagamento)
    • Pagamento programmato (funzionalità fortemente consigliata per l'alto valore percepito dagli utenti)
    • Pagata (con CTA per la ricevuta)
    • Scaduta (stato ben visibile che comunica l'impossibilità di pagare)
    • Annullata (es. revocata dall'ente o pagata su altri canali), mantenendo i dettagli ma spiegando perché non è pagabile?

Gestione Errori e Assistenza

  • I messaggi di errore sono contestualizzati e non generici (es. NO "Errore tecnico")?
  • Il messaggio di errore identifica chiaramente l'attore risolutivo (Ente Creditore, Banca/PSP, o pagoPA)?
  • Per errori di contenuto o stato (es. "Avviso scaduto", "Avviso revocato", "Importo non corretto"), l'utente viene indirizzato a contattare l'Ente Creditore?
  • Per errori tecnici della piattaforma (es. "Problema tecnico con questo avviso"), l'utente viene invitato ad aprire una segnalazione all'assistenza del PSP?
  • Per "Pagamento in corso", l'utente viene invitato ad attendere e poi, se il problema persiste, a contattare l'assistenza del PSP?
  • Quando un utente segnala un problema, riceve un feedback di presa in carico (es. codice ticket)?

Attivazione e disattivazione

Adesione (Opt-In) e Privacy

  • L'adesione al servizio richiede un'attivazione esplicita dell'utente (flusso di "opt-in")?
  • È stato chiarito all'utente che l'adesione non comporta un addebito automatico?
  • L'utente viene informato su quali dati personali sono necessari per l'attivazione?
  • Vengono rese visibili e accessibili sia l'Informativa Privacy del PSP che quella di PagoPA?
  • All'utente è data la possibilità di scegliere i canali di notifica preferiti (es. push, email)?
  • È garantita all'utente la possibilità di disattivare il servizio in qualsiasi momento, in una sezione chiara e raggiungibile?

Disattivazione e trasferimento dei Servizi

  • L'utente può trovare facilmente l'opzione per disattivare il servizio in autonomia?
  • L'utente riceve una conferma esplicita dell'avvenuta disattivazione?
  • Flusso di Trasferimento:
    • Quando un utente attiva il servizio sul nuovo PSP (il tuo), viene informato che il servizio si disattiverà automaticamente sul vecchio PSP?
    • È stato implementato il flusso di notifica per avvisare l'utente quando il servizio viene disattivato automaticamente perché lo ha attivato presso un altro PSP?

(Consigliato) Voice of Customer

Raccolta Feedback

  • È stato previsto un meccanismo (es. nella schermata di dettaglio) per raccogliere feedback volontario dall'utente?
  • Il feedback permette di mappare cause comuni di abbandono (es. "Dati non corretti", "Ho già pagato", "Non riconosco questo avviso")?