Da quello che leggo sull’attuale versione della Monografia Processo di pagamento presso il PSP con Ente multi-beneficiario
I requisiti descritti nel presente documento saranno recepiti nelle nuova versione delle SANP (2.4.0), e disponibili in ambiente di test entro Marzo 2021.
L’adeguamento alle nuove interfacce, secondo SANP 2.4.0, di un PSP potrà avvenire senza particolari vincoli o modifiche della configurazione, purché avvenga entro il termine ultimo fissato al 01/05/2021.
ne deduco che
- dati i tempi indicati a brevissimo usciranno le SANP 2.4.0 che deprecheranno le 2.3.0
- verra’ introdotto il nuovo modello 3 lasciando comunque attivo l’attuale fino a fine anno 2021 (termine ultimo per l’adeguamento degli EC)
- il nuovo modello 3 sarà in test entro marzo (non è specificata una data esatta)
- i PSP devono obbligatoriamente implementare il nuovo modello 3 entro il primo maggio
e quindi propongo alcune mie osservazioni, vedendo le cose lato PSP
Retrocompatibilità
Qual’è il senso della frase “Le interfacce saranno retrocompatibili con quelle attuali (rif SANP 2.3.0)” ?
Ci sara’ un periodo di duality, da maggio fino a, immagino, fine anno in cui verranno usate le intefacce vecchie e nuove.
I dati saranno sempre quelli naturalmente, ma in formato diverso (niente piu’ strutture RPT ed RT). Sparisce il CCP creato dal PSP e in maniera simile lo sostituisce il token creato dallla PA. C’è la novità del timeout e dell’idempotenza.
Quindi non capisco in cosa consista questa retrocompatibilità.
Oppure, ma è un pensiero ardito, il Nodo si propone come adattatore tra le nuove e le vecchie interfacce. Cioè un PSP potrebbe da maggio usare per il modello 3 solo le nuove interfacce e il Nodo pensa ad adattarle alle vecchie nel colloquio con la PA.
Però la vedo molto dura, quantomeno per la sparizione dell’asincrona pspInviaRPT sostituita (finalmente) dalla response della activatePaymentNotice
Ex Aux Digit 4
La prima versione della monografia diceva:
Affinché un PSP possa, a fronte della presentazione di un Avviso di Pagamento, discriminare quale processo di pagamento attuare, gli avvisi di pagamento emessi dagli Enti che saranno identificati da un aux-digit pari a 4 (rif. SACI).
nella versione attuale l’aux digit 4 e’ sparito e credo che la sua funzionalità sia stata sostituita dal parametro version:
Per l’adeguamento alle nuove interfacce di un EC è necessaria una modifica della propria configurazione che deve avvenire entro il termine ultimo fissato al 31/12/2021, decorso tale termine le vecchie interfacce (secondo SANP 2.3.0) saranno dismesse dalla piattaforma pagoPA per tutti gli EC.
La modifica della configurazione è attuata tramite ulteriori funzioni della sezione stazione del PdA che consentono di gestire i seguenti ulteriori parametri:
version (n.n.n) - indica la versione delle interfacce esposte dalla stazione: deve corrispondere al parametro version indicato nei WSDL paForNode.wsdl.
broadcast (true/false) - il valore true caratterizza una stazione come adeguata a ricevere le RT in qualità di Ente beneficiario gestite da EC terzi (rif. UC-EC-040 nel presente documento).
I parametri in parola saranno assegnati alle stazioni attualmente esistenti con opportuno valori di default.
Come si dovrà quindi fare per determinare se un EC supporta le nuove interfacce o meno ? Questi dati saranno presenti nella lista PA e dovranno essere ricercati ogni volta che si inizia un pagamento modello 3 ?
Idempotenza verifica
Per la nuova primitiva verifyPaymentNotice e’ scritto che
In caso di timeout, la funzione può essere nuovamente invocata.
Vorrei la conferma che in ogni caso, cioè indipendentemente da timeout, la verifyPaymentNotice possa essere ripetutamente invocata.
Ma quello che più mi interessa è sapere cosa risponde la verifyPaymentNotice qualora la posizione sia già stata “attivata” da un altro PSP ma non ancora confermata come pagata da una sendPaymentOutcome positiva.
Io vorrei che fosse anche in questo caso idempotente e che poi l’attivazione fosse bloccata con un KO sulla activatePaymentNotice
O meglio, non esattamente idempotente, cioè è giusto che la verifica mostri sempre i dati più aggiornati della posizione, se potenziamente ancora pagabile. Ma non vorrei che, com’è ora, la verifica restituisca un errore se semplicemente e’ attivata (ma non ancora pagata) da un altro PSP.
Riformulo usando gli stati della richiesta di pagamento proposti: la verifica deve funzionare allo stesso modo sia che il pagamento sia in “valid” che in “paying” mentre tornerà un errore se è in “paid” o altro stato.
La logica è che sia molto improbabile che una posizione venga pagata contemporaneamente da due parti.
Infine: la verifica sarà obbligatoria o facoltativa ?
Pagamento rateale
Secondo la monografia
Un avviso di pagamento può essere associato a diverse richieste di pagamento (Service), per ognuna delle quali sarà disponibile al più una ricevuta di pagamento (ServiceReceipt).
e io ci vedo per esempio l’avviso analogico dove infatti si possono mettere più rate con eventualmente anche il pagamento in un’unica soluzione. Ed ogni rata però ha il suo proprio IUV come un’ulteriore IUV differente è attribuito all’eventuale unica soluzione.
Più avanti però si dice che
Un Avviso di pagamento è composto da :
- un identificativo univoco per l’Ente Creditore (Numero Avviso)
- …
- un flag “pagamento rateale” che identifica se si tratta di una rata di un piano di pagamento e quindi informa che lo stesso avviso potrebbe essere stato utilizzato in passato.
- …
Quindi vorrei capire cos’è quel “identificativo univoco per l’Ente Creditore (Numero Avviso)”. E’ per esempio l’unico Numero Avviso presente nel caso di singolo pagamento oppure quello dell’unica soluzione nel caso di pagamento rateale con questa opzione ?
Oppure è qualcosa di diverso, più simile ad un identificativo di carrello come per i pagamenti modello 1 ?