No, Checkout non è cambiato. La stessa versione di Checkout supporta sia la versione 1 che la versione 2 delle api

Attualmente viene generata una ricevuta nel momento in cui l’utente effettua il login su Checkout, ricevuta che viene inviata al cittadino su app IO.
Questa ricevuta, come riportato anche all’interno della stessa, attesta il pagamento effettuato su piattaforma pagoPA. NON si tratta di una quietanza liberatoria, la stessa rimane sotto responsabilità dell’Ente creditore nella parte di generazione e comunicazione al cittadino

Si, rimarrà tale anche per la versione 2 delle api

Dipende dal punto di “rottura” della transazione. Se non viene ricevuto outcome dell’autorizzazione il timeout è quello della durata del payment token, ovvero 15 minuti.
In caso di mancata chiusura del flusso lato Nodo/PSP il tempo massimo si potrebbe protrarre

Il pagamento innescato da POST /carts gestisce fino a 5 avvisi per singola transazione, permettendo all’utente di pagare gli avvisi in un’unica transazione.
Non è supportato il pagamento parziale: se uno degli avvisi nel carrello non è pagabile (ad es. avviso non esistente o già pagato) allora l’intero carrello non sarà pagabile

In fase di pagamento dell’avviso viene effettuata l’activatePaymentNotice verso il Nodo che causa, oltre l’attivazione della transazione, l’attualizzazione dell’importo dell’avviso di pagamento, che sarà oggetto del pagamento da parte del cittadino.
Per la parte di descrizione e companyName si potrebbe adottare lo stesso approccio, ovvero “attualizzare” descrizione e company name con quanto ricevuto in risposta sull’activate, sovrascrivendo i dati forniti in input.
Sarebbe utile, comunque, condividere, tramite gli appositi canali, i concern di sicurezza inerenti il fatto di usare i dati in input alla POST carts per indirizzare meglio le analisi

In fase di atterraggio su Checkout viene effettuata una chiamata interna di check dei dati inseriti sul Nodo, pertanto se la posizione è stata creata pochi istanti prima di effettuare la chiamata verso Checkout potrebbe darsi che la stessa non risulti essere ancora “visibile”

Si

Si, valgono le stesse considerazioni effettuate per le altre urls

No, non è previsto un URL per il download di ricevute per l’integratore.
Seguendo le SANP il flusso di pagamento si conclude con la paSendRT scatenata dal Nodo verso l’EC a valle della chiusura con successo del flusso di pagamento: con questa chiamata l’EC riceve ricevuta di avvenuto pagamento dell’avviso

Confermiamo che l'API 'GPD - Recupero receipt' supporta attualmente entrambi i formati. È possibile valorizzare i parametri from e to per la ricerca delle paSendRT sia utilizzando il formato yyyy-MM-dd sia quello esteso yyyy-MM-ddTHH:mm:ss.
Qualora si dovessero riscontrare errori di validazione utilizzando il formato con orario, invitiamo a fornire un esempio della request per permettere di effettuare ulteriori verifiche.
Cogliamo l’occasione per segnalare che le specifiche SANP-3.12.0 forniranno una documentazione più dettagliata di questi parametri.

ogni EC può generare quietanza di pagamento verso il cittadino alla ricezione della paSendRT da parte del Nodo

Entrambe le modalità di integrazione pagoPA risultano pienamente supportate e attivamente mantenute; pertanto, non si configura una scelta obbligata in termini assoluti.

La valutazione comparativa tra le due modalità deve essere effettuata tenendo conto delle specifiche esigenze dell’Ente Creditore, con particolare riferimento al livello di controllo richiesto sulle posizioni debitorie, alla complessità dei processi amministrativi e allo stato evolutivo dei sistemi informativi interni.

In tale contesto, la modalità asincrona (GPD) presenta un evidente vantaggio operativo, in quanto la gestione delle posizioni debitorie, nell’ambito del flusso di pagamento, è demandata alla piattaforma pagoPA, con conseguente semplificazione degli adempimenti lato Ente e riduzione delle necessità di sviluppo e manutenzione di logiche applicative proprietarie.

Per contro, la modalità di integrazione sincrona risulta maggiormente adeguata nei casi in cui sia richiesto un più elevato livello di controllo diretto, ovvero nei contesti caratterizzati dalla presenza di sistemi legacy già strutturati e consolidati.

Non si rileva, pertanto, una soluzione univocamente preferibile, dovendosi piuttosto procedere a una valutazione caso per caso, in funzione del contesto organizzativo dell’Ente e degli obiettivi di evoluzione del relativo ecosistema informativo.

Dipende dal punto di “rottura” della transazione. Se non viene ricevuto outcome dell’autorizzazione il timeout è quello della durata del payment token, ovvero 15 minuti.
In caso di mancata chiusura del flusso lato Nodo/PSP il tempo massimo si potrebbe protrarre

Alla data odierna, l’API “GPD - Recupero flussi di rendicontazione” risulta ancora disponibile e utilizzabile; tuttavia, ne è prevista la progressiva dismissione nell’ambito delle prossime evoluzioni delle SANP (3.12.0) di pagoPA.

Si raccomanda, pertanto, l’adozione del nuovo servizio “FdR - Flussi di Rendicontazione (ORGs)”, al fine di beneficiare dell’utilizzo di standard JSON e di una gestione più efficiente e scalabile dei flussi di rendicontazione, in particolare per volumi di grandi dimensioni.