Pagamento presso frontend dell'EC
Questo processo viene attivato nel momento in cui l'operazione di pagamento è avviata dal front end di un EC, il workflow si prefigge lo scopo di aver minor impatto possibile su EC e PSP, infatti, le interfacce di comunicazione sono le stesse utilizzate per il pagamento presso i PSP, quindi ne condividono tutti i presupposti.
![](https://docs.pagopa.it/~gitbook/image?url=https%3A%2F%2F3680717072-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FxStAOBVhMPuBPPjhED2d%252Fuploads%252FGWv0fR1ZV77uAjTBiQwN%252Fnuovo_modello1_carrello_V3_SANP.png%3Falt%3Dmedia%26token%3D2c1a85e2-82c9-4e8c-918f-c3c07448b54c&width=768&dpr=4&quality=100&sign=23a575f4&sv=1)
quando il front end dell'EC riceve la richiesta di pagamento di uno o più avvisi la inoltra con una redirect a Checkout, l'interfaccia di front end di PagoPA S.p.A.;
Checkout, in base al numero di avvisi che ha ricevuto, chiede al Nodo di attivare gli n pagamenti presso l’EC;
ogni singola richiesta di attivazione di pagamento giunge all’EC per mezzo della paGetPayment;
Checkout gestisce le operazioni di pagamento effettivo da parte dell'utente, una volta concluse effettua una redirect verso il frontend dell'EC e invia gli esiti al Nodo che provvede ad inviarli al PSP tramite la pspNotifyPayment vers. 2, nel caso di risposta KO da parte del PSP il processo viene interrotto e il pagamento deve essere stornato;
a fronte di eccezioni tecniche durante la chiamata alla pspNotifyPayment vers. 2 che impedissero di ricevere una response, il Nodo attenderebbe il verificarsi del primo dei seguenti eventi
scadenza del payment token: il processo viene interrotto e il pagamento deve essere stornato;
ricezione della sendPaymentOutcome vers. 2: il flusso procede normalmente, tenendo sempre presente che il PSP non può inviare un outcome = KO;
nel caso il PSP inviasse una sendPaymentOutcome vers. 2 dopo aver risposto con un KO alla pspNotifyPayment vers. 2 il Nodo risponderebbe con un KO per segnalare l'esito discorde;
in caso di accettazione della pspNotifyPayment vers. 2 il PSP è tenuto a fornire l'esito del pagamento entro 2sec con la sendPaymentOutcome vers. 2, che contiene un singolo outcome per tutti i tokens attivati nelle fasi precedenti;
se il PSP inviasse un outcome = KO dopo aver accettato la pspNotifyPayment vers. 2 il Nodo risponderebbe con un KO per segnalare l'esito discorde;
tramite la primitiva paSendRT viene inoltrata agli n EC interessati al pagamento la receipt (ricevuta) solo se il pagamento è stato effettuato, la receipt è un oggetto generato dalla piattaforma pagoPA;
quando l'EC riceve la receipt deve chiudere la posizione debitoria e considerarla interamente saldata.
Per la gestione degli errori fare riferimento a Gestione degli errori.
Per un corretto e standardizzato utilizzo dei metadata è stato creato un apposito Dizionario dei metadata, in cui è presente una sezione dedicata alle informazioni del canale di pagamento presenti in additionalPaymentInformations della pspNotifyPayment vers. 2.
Last updated