LogoLogo
SANPSACITutto il resto
SANP 3.6.1
SANP 3.6.1
  • ⬅️Torna a pagoPA.gov.it
  • Specifiche attuative del nodo dei pagamenti SPC
    • Premessa
    • Changelog
    • Glossario
    • Roadmap
    • Documentazione
    • Funzionamento generale
      • Ruoli
      • Ciclo di vita di un pagamento
      • Processi di pagamento
      • Rendicontazione e Cashflow
      • Overview delle componenti
      • Sicurezza e conservazione
      • L’adesione alla piattaforma pagoPA
      • Utilizzo del marchio pagoPA
      • Stand In
    • Erogazione e Livelli di servizio
    • Modello dati
  • Casi d'uso
    • Pagamento di un avviso presso PSP
    • Pagamento spontaneo presso PSP
      • Catalogo dei servizi
      • Bollo auto
    • Pagamento presso frontend dell'EC
    • Pagamento da Touchpoint PagoPA
      • Checkout
      • App IO
  • Ente Creditore
    • Adesione
    • Modalità d'integrazione
      • Integrazione tramite API asincrone
      • Integrazione tramite API sincrone
      • Integrazione touch point dell’EC con Checkout
      • Best practice
    • Generazione dell’Identificativo Univoco di Versamento
    • Tassonomia dei servizi di incasso
    • Tributi multi-beneficiario
    • Attestazione di pagamento
    • Riconciliazione contabile
    • Servizio @e.bollo
    • Stampa avvisi pagoPA
    • Processo di avvio in Esercizio
  • Prestatore di Servizi di Pagamento
    • Adesione
    • Modalità di integrazione
      • Integrazione tramite API
      • Catalogo Dati Informativi
      • Offrire sistemi di pagamento su touchpoints di PagoPA S.p.A.
      • Integrazione standard per gli strumenti di pagamento
      • Integrazione per strumento di pagamento PayPal
      • Integrazione per strumento di pagamento tramite Redirect
      • Best practice
    • Commissioni
    • Attestazione di pagamento
    • Processo di avvio in Esercizio
  • Esperienza per il Cittadino
    • App IO
      • Carte
      • PayPal
    • Checkout
  • Appendici
    • Connettività
    • Indicatori di qualità per i soggetti aderenti
      • Livelli di Servizio Enti Creditori
      • Livelli di Servizio PSP
    • Giornale degli eventi
    • Generazione e stampa degli avvisi
    • Gestione evoluta commissioni
    • Primitive
    • Funzionalità deprecate
    • Adesione ai servizi con subscription key
    • Posizioni Debitorie
      • Modello Dati
      • Stati della posizione debitoria
      • Pagamenti presso frontend dell'EC in modalità asincrona
      • Operazioni disponibili
    • POS Fisici
  • FAQ
    • Ente Creditore
    • PSP
    • Intermediario tecnologico
Powered by GitBook
On this page
  1. Casi d'uso

Pagamento presso frontend dell'EC

PreviousBollo autoNextPagamento da Touchpoint PagoPA

Questo processo viene attivato nel momento in cui l'operazione di pagamento è avviata dal front end di un EC, il workflow si prefigge lo scopo di aver minor impatto possibile su EC e PSP, infatti, le interfacce di comunicazione sono le stesse utilizzate per il pagamento presso i PSP, quindi ne condividono tutti i presupposti.

  • quando il front end dell'EC riceve la richiesta di pagamento di uno o più avvisi la inoltra con una a Checkout, l'interfaccia di front end di PagoPA S.p.A.;

  • Checkout, in base al numero di avvisi che ha ricevuto, chiede al Nodo di attivare gli n pagamenti presso l’EC;

  • ogni singola richiesta di attivazione di pagamento giunge all’EC per mezzo della ;

  • Checkout permette al PSP aderente, che offre all’interno della piattaforma pagoPA i propri strumenti di pagamento digitali (Offrire sistemi di pagamento su touchpoints di PagoPA S.p.A.), di incassare la somma dovuta dall'utente;

  • una volta concluse le operazioni di pagamento, Checkout effettua una redirect verso il frontend dell'EC e invia gli esiti al Nodo che provvede ad inviarli al PSP tramite la , nel caso di risposta KO da parte del PSP il processo viene interrotto e il pagamento deve essere stornato;

  • a fronte di eccezioni tecniche durante la chiamata alla che impedissero di ricevere una response, il Nodo attenderebbe il verificarsi del primo dei seguenti eventi

    • scadenza del payment token: il processo viene interrotto e il pagamento deve essere stornato;

    • ricezione della : il flusso procede normalmente, tenendo sempre presente che il PSP non può inviare un outcome = KO;

  • nel caso il PSP inviasse una dopo aver risposto con un KO alla il Nodo risponderebbe con un KO per segnalare l'esito discorde;

  • in caso di accettazione della il PSP è tenuto a fornire l'esito del pagamento entro 2sec dall'accettazione con la , che contiene un singolo outcome per tutti i tokens attivati nelle fasi precedenti;

  • se il PSP inviasse un outcome = KO dopo aver accettato la il Nodo risponderebbe con un KO per segnalare l'esito discorde;

  • tramite la primitiva viene inoltrata agli n EC interessati al pagamento la receipt (ricevuta) solo se il pagamento è stato effettuato, la receipt è un oggetto generato dalla piattaforma pagoPA;

  • quando l'EC riceve la receipt deve chiudere la posizione debitoria e considerarla interamente saldato l’avviso oggetto del pagamento.

Per la gestione degli errori fare riferimento a .

Per un corretto e standardizzato utilizzo dei metadata è stato creato un apposito , in cui è presente una sezione dedicata alle informazioni del canale di pagamento presenti in additionalPaymentInformations della .

redirect
Dizionario dei metadata
Gestione degli errori
pspNotifyPayment vers. 2
paGetPayment
pspNotifyPayment vers. 2
pspNotifyPayment vers. 2
sendPaymentOutcome vers. 2
sendPaymentOutcome vers. 2
pspNotifyPayment vers. 2
pspNotifyPayment vers. 2
sendPaymentOutcome vers. 2
pspNotifyPayment vers. 2
paSendRT