Tabella dei contenuti
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.
- 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 permette al PSP aderente, che offre all’interno della piattaforma pagoPA i propri strumenti di pagamento digitali (Offrire sistemi di pagamento su touchpoints di PagoPA S.p.A.), di incassare la somma dovuta dall'utente;
- una volta concluse le operazioni di pagamento, Checkout 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 dall'accettazione 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 saldato l’avviso oggetto del pagamento.
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.
Dicci cosa ne pensi
Per chiarimenti sulle specifiche d’implementazione, come SACI e SANP, puoi aprire una segnalazione su GitHub