torno in topic, cioè sul servizio per avviare pagamenti dal sito pagopa avendo a disposizione un avivso:
MI chiedo e vi chiedo (@nardil ), se potesse essere sensata un’evolutiva di pagoPA a partire da questo servizio nei termini che seguono.
Scenario d’uso:
servizio online dell’EC che a un certo punto genera un’esigenza di pagamento.
ormai, essendo fuori dal perimetro di pagoPA spa, piu’ o meno tutti i PT/sistemi pagoPA mettono a disposizione delle API per creare un dovuto da pagare e poi per verificarne lo stato di pagamento;
non esiste uno standard per fare quanto al punto precedente, ma ormai e’ andata, ci siamo aggiustati (a suon di spese di sviluppi ad hoc i vari attori ICT stanno imparando a parlare tra loro);
è invece più difficile trovare API ragionevoli per avviare il pagamento di uno IUV (modello 1?) e ricevere in tempo reale esito di quanto avvenuto nello WISP (pagamento ok, ko, annullato ecc.)
Ecco la domanda: questo servizio checkout potrebbe essere, con le dovute aggiunte, utilizzato per lo scopo?
Ipotetico flusso:
il servizio online crea il pagamento dovuto interfacciandosi con il PT/sistema dei pagamenti dell’EC;
acquisisce il codice avviso e unendoci il CF dell’EC avvia il pagamento tramite il servizio di PagoPA spa;
di ritorno dallo WISP si veicolano al sistema chiamante (che probabilmente avrà fornito al punto precedente delle URL da chiamare in base agli esiti - dettagli tecnici) le informazioni sull’esito del pagamento;
l’utente torna sul servizio online dell’EC e da lì prosegue in base all’esito del pagamento su WISP (secondo logiche del servizio online).
Vantaggi: si uniformerebbe questa operazione per tutti i servizi online e si eviterebbe di dover sviluppare integrazioni ad hoc. In altri termini, il servizio online dovrebbe implementare solo il dialogo con il PT per creazione IUV e recupero ricevuta esito (se uno paga offline o comunque extra servizio on line), ma la parte di avvio del pagamento online sarebbe uguale per tutti, quindi i software arriverebbero con questa funzione già a bordo, non piu’ da negoziare.
forse non ho capito cosa intendi, ma mi sembra che INPS (contributi colf), ACI (pagamanto bollo) ed il Comune di Palermo (sono quelli che ho personalmente provato) funzionino così.
Certo, non so cosa abbiano dovuto sviluppare in house…
E’ una questione un po’ sottile in effetti.
Si’ quei servizi che citi sicuramente hanno implementato il loro modo di avviare il pagamento e interagire con WISP. Interazione che deve passare dal PT che credo sia l’unico in grado di usare le API del nodo dei pagamenti SPC.
Si tratta appunto di minimizzare gli sviluppi. Oggi come oggi se io voglio avviare un pagamento da dentro il servizio online devo dialogare con il mio PT. Questo, se mette a disposizione la funzione, lo fa con API sue proprietarie e quindi è uno sviluppo.
Se invece che bussare al mio PT X il servizio online del fornitore Y potesse bussare a checkout.pagopa.it, il fornitore Y farebbe un solo sviluppo utilizzabile da tutti gli EC che gli comprano quel servizio (e avrebbe risorse da utilizzare per migliorare il servizio invece che fare business sull’allestimento delle funzioni di base, fra l’altro).
Sono riuscito a essere meno chiaro?
Mi sembra che tu auspichi ad un servizio centralizzato (checkout.pagopa.it) per uniformare il colloquio con pagoPA dal punto di vista del fornitore. In tal caso esiste gia’ e sono appunto le API native di pagoPA. Implementandole, diventi di fatto un PT.
esempio: portale di candidatura a un concorso. voglio che chi me lo fornisca non sia un PT ma si metta in dialogo col mio. mi piacerebbe pero’ che non dovesse sviluppare Nmila connettori, visto che siamo fuori perimeto pagoPA. Ormai a una chiamata standard per creare il dovuto ci rinuncio. Pero’, adesso che esiste uno strumento esterno per avviare un pagamento, mi chiedevo solo se si riuscisse ad invocarlo con una API (che curasse anche il ritorno OK/KO al servizio chiamante). Cosi’ il venditore del portale di candidature ai concorsi sviluppa un connettore uno. Questo non lo fa diventare un PT; come chekout non è un PT.
Sto solo cercando di capire se ha una fattibilità:
quindi una sorta di tabaccaio-pagopa che poi genera la parte tecnologica (rpt) e manda i soldi sul conto?
non proprio. solo il servizio checkout.pagopa.it cosi’ come e’ solo che attivato da un servizio esterno e non da un omino che digita numero avviso e codice fiscale. e in più deve dare un ritorno sull’esito del pagamento al servizio esterno che lo ha avviato (verosimilmente tramite due URL distinti uno per OK uno per KO, come credo funzioni adesso anche checkout.pagopa.it
Una prima difficoltà tecnico-amministrativa che mi viene in mente è che checkout.pagopa.it dovrebbe garantire una certa continuità di servizio a dei perfetti sconosciuti…
