LogoLogo
SANPSACITutto il resto
SANP 3.2.2
SANP 3.2.2
  • ⬅️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
      • Sicurezza e conservazione
      • L’adesione alla piattaforma pagoPA
      • Utilizzo del marchio pagoPA
    • Erogazione e Livelli di servizio
    • Specifiche tecniche
    • 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
      • Integrazione touch point dell’EC con Checkout
      • Integrazione tramite Gestione Posizioni Debitorie
      • Best practice
    • Generazione dell’Identificativo Univoco di Versamento
    • Tassonomia dei servizi di incasso
    • Tributi multi-beneficiario
    • Attestazione di pagamento
    • Riconciliazione contabile
    • Servizio @e.bollo
    • 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 touch point di PagoPA S.p.A.
      • Gestione strumenti di pagamento
      • 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
    • Generazione e stampa degli avvisi
    • Gestione evoluta commissioni
    • Primitive
    • Funzionalità deprecate
    • Posizioni Debitorie
      • Adesione tecnica al servizio
      • Modello Dati
      • Stati della posizione debitoria
      • Operazioni disponibili
  • FAQ
    • Ente Creditore
    • PSP
    • Intermediario tecnologico
Powered by GitBook
On this page
  • Gestione della posizione debitoria
  • Causale di versamento
  • Fase di verifica
  • Fase di attivazione
  • Bollettino Postale PA
  • Coda delle receipt da risottomettere
  1. Ente Creditore
  2. Modalità d'integrazione

Best practice

PreviousIntegrazione tramite Gestione Posizioni DebitorieNextGenerazione dell’Identificativo Univoco di Versamento

Last updated 2 years ago

Gestione della posizione debitoria

L’EC crea una posizione debitoria in attesa nell'archivio dei pagamenti, e vi associa un numero avviso. Nella versione attuale del software è previsto il pagamento in un’unica soluzione.

L'EC nelle fasi intermedie del pagamento non deve modificare lo stato della posizione, che rimane sempre nello stato "aperta", è cura della piattaforma pagoPA gestire gli stati intermedi, l'EC modifica la posizione debitoria in stato “pagato” solo se il pagamento va a buon fine.

In questo caso la posizione risulta interamente saldata, esiste quindi un solo pagamento “pagato” associato alla posizione debitoria.

Causale di versamento

A partire dalla versione 2.0.0 delle SACI è stato rimosso il capitolo "Formato della causale di versamento", per la composizione di tale dato si deve fare riferimento direttamente al paragrafo 7.1 delle Linee Guida.

Si raccomanda di non inserire all'interno della causale di versamento dati personali e/o dati particolari.

Fase di verifica

La richiesta di verifica avviene sempre per mezzo della primitiva , sia nel caso di che nel caso di , anche perché l'EC non è a conoscenza da quale primitiva sia nata la verifica.

L’EC deve rispondere sempre con un unica opzione di pagamento e per mezzo del parametro allCCP deve sempre indicare se la posizione debitoria è associabile a tutti conti correnti postali o meno:

  • allCCP = true : l’opzione è associabile a tutti Conti Correnti Postali;

  • allCCP = false: l’opzione non è associabile a tutti Conti Correnti Postali.

Fase di attivazione

Nella fase di attivazione l'EC è sempre tenuto ad attualizzare l'importo del pagamento.

Per mezzo del parametro transferType la piattaforma richiede all’EC per ogni singolo transfer:

  • i conti correnti postali (quando disponibili) con il parametro transferType=POSTAL;

  • qualsiasi conto corrente, a discrezione dell’EC stesso, se il parametro transferType non è indicato.

Il parametro retentionDate al momento viene ignorato dalla piattaforma pagoPA.

Il parametro lastPayment al momento viene ignorato dalla piattaforma pagoPA.

Bollettino Postale PA

Coda delle receipt da risottomettere

  • se una receipt viene sottomessa nuovamente e va in uno stato finale si toglie dalla coda;

  • se una receipt viene sottomessa nuovamente ma rimane in uno stato non finale (NOTICE_PENDING) si lascia in coda e si aumenta il contatore relativo al numero di retry.

Raggiunto il numero finale di retry (è un parametro di configurazione della piattaforma) il processo si ferma e l'elemento rimane in coda, è possibile riavviare il processo di retry con una richiesta all'assistenza di PagoPA S.p.A..

Se l'EC dispone di un conto corrente postale per gli incassi è necessario includere nell'avviso di pagamento anche il Bollettino Postale PA, in tal caso se nella request della il parametro transferType fosse valorizzato a POSTAL al transfer con idTransfer = 1 deve essere per forza associato l'IBAN di un conto corrente postale.

In caso di una risposta alla che porta la receipt in stato NOTICE_PENDING (timeout, errore response, non raggiungibile), la receipt viene inserita in una coda per essere sottomessa nuovamente all’EC.

Con la primitiva il nodo cerca di sottomettere nuovamente le receipt in questione:

paVerifyPaymentNotice
verificaBollettino
verifyPaymentNotice
paGetPayment
paSendRT
paSendRT