[RFC]paGetPayment: uso dei parametri amount e dueDate

[lucagargiulo]

Nella paGetPayment, oltre al qrCode posso ricevere i seguenti 4 valori:
<xsd:element name="amount" type="tns:stAmount" minOccurs="0" />
<xsd:element name="paymentNote" type="tns:stText210" minOccurs="0" />
<xsd:element name="transferType" type="tns:stTransferType" minOccurs="0" />
<xsd:element name="dueDate" type="tns:stISODate" minOccurs="0" />
Sono tutti opzionali: è corretto che sia così?
Con il qrCode posso recuperare dai dati dell'APA le opzioni di pagamento disponibili: spesso al qrCode è associata una sola opzione e non ci sono problemi.
In altri casi devo scegliere fra più opzioni, usando amount e dueDate per individuare quella giusta.
Se non ho informazioni sufficienti per individuare un'unica opzione devo restituire un fault?

[gammam]

Avendo avuto dei riscontri negativi in fase di test, l’opzione di poter identificare , a fronte dello stesso avviso, diverse opzioni di pagamento è attualmente in stand-by. Pertanto gli unici parametri che saranno popolati nell’invocazione della paGetPayment sono :

amount : corrispondente all’ammontare del pagamento riportato all’interno dell’avviso ( letto tramite QR-CODE )

transferType : che indica alla PA di restituire le transferType afferenti al bollettini postale allegato all’avviso. Nel particolare , qualora dovesse arrivare una chiamata con trasferType=POSTAL la PA deve popolare necessariamente la transferType verso se stessa con il conto corrente postale indicato nel bollettino postale. I conti correnti di altri enti possono essere bancari o postali in maniera indistinta, purchè coerenti con quanto risposto alla paVerifyPaymentNotice

[lucagargiulo]

@gammam qual è il significato della frase

l’opzione di poter identificare , a fronte dello stesso avviso, diverse opzioni di pagamento è attualmente in stand-by?

La roadmap prevedeva che dal 1 maggio i PSP dovessero rilasciare in produzione il supporto alle specifiche e due giorni fa il nostro account PagoPA ci ha confermato che i PSP hanno implementato e sono in produzione con il nuovo modello.
Quindi un ente creditore potrebbe già oggi essere in produzione con le nuove specifiche. Non sono in grado di verificare la l'affermazione ma questa è la versione ufficiale.
Le specifiche ad oggi prevedono che la paVerifyPaymentNotice possa fornire una o più opzioni (tecnicamente anche 0, ma posso supporre che tale eventualità debba essere usata solo in caso di outcome KO).
La possibilità di fornire più opzioni ha un impatto forte sull'architettura dell'infrastruttura di intermediazione necessaria per fornire adeguato supporto a tale feature. Personalmente la ritengo una caratteristica interessante del nuovo modello e la flessibilità che ne deriva vale l'investimento, ma l'opportunità di prevederla o meno andava valutata prima. Credo che sia gli intermediari/partner lato EC che i PSP abbiano investito delle risorse per analizzare l'impatto di questa feature e implementarla nel modo più adeguato, quindi un ripensamento a questo punto mi sembra tardivo. In ogni caso, ripeto, le specifiche e la documentazione pubblicate attualmente prevedono che venga restituita una lista di opzioni, quindi per favore chiarisci cosa intendi con è "attualmente in stand-by" perchè l'impatto è molto alto ed il comportamento atteso è completamento diverso:

se non esiste una lista di opzioni, significa che il noticeNumber deve individuare esattamente un pagamento come nelle vecchie specifiche quindi di fatto rimane accoppiato allo iuv (la cosa ha conseguenze importanti, non è un dettaglio)

se ad un noticeNumber sono associate più opzioni allora dalla request della paGetPayment devo essere in grado di identificare l'opzione giusta e quindi è necessario chiarire:

• cosa deve obbligatoriamente contenere un'opzione (quali campi sono obbligatori e quali no)
• quali sono i campi che devono essere obbligatori nella request della paGetPayment (se deve esserci l'amount letto dal QRCode forse va estesa la struttura QRCode con l'Amount obbligatorio)
• se devo generare un fault nel caso in cui l'informazione contenuta nella request non mi consenta di identificare una e una sola opzione di pagamento (e cosa vi aspettate che faccia in tal caso il PSP per consentire il pagamento)

By the way: sarebbe il caso di pubblicare, come già richiesto in altra RFC, anche i fault code previsti lato EC, attualmente è riportata in commento una lista di quelli usati per i PSP.