Table of contents
Payment at the EC’s frontend
This process is activated the moment in which the payment operation starts at the creditor’s frontend, the workflow serves the purpose of having as little impact as possible on the creditor and PSP. In fact, the communication interfaces are the same used for the payment at the PSPs, therefore they share all the prerequisites.
- when the creditor’s frontend receives the payment request for one or more notices, it forwards it with a redirect to Checkout, the front-end interface of PagoPA S.p.A.;
- Checkout, based on the number of notices it received, requests the Node to activate the n payments at the creditor;
- Each individual request to activate the payment reaches the creditor by means of paGetPayment;
- Checkout permits the registered PSP, who offers their digital payment instruments on the pagoPA platform (Offering payment systems on PagoPA S.p.A. touchpoints), to collect the amount due from the user;
- once the payment operation is complete, Checkout performs a redirect to the frontend of the creditor and sends the outcomes to the Node that then sends them to the PSP via the pspNotifyPayment vers. 2, in the case of a KO response from the PSP, the process is interrupted and the payment must be canceled;
- in the case of technical exceptions during the call to pspNotifyPayment vers. 2 which prevents receiving a response, the Node would wait for the first of the following events to occur
- expiration of the payment token: the process is interrupted and the payment must be canceled;
- reception of the sendPaymentOutcome vers. 2: the flow proceeds normally, always keeping in mind that the PSP cannot send an outcome = KO;
- if the PSP sends a sendPaymentOutcome vers. 2 after responding with KO to pspNotifyPayment vers. 2 the node would respond with KO to signal the discordant outcome;
- in case of acceptance of the pspNotifyPayment vers. 2 the PSP is required to provide the outcome of the payment within 2sec from acceptance with the sendPaymentOutcome vers. 2, that contains a single outcome for all tokens activated in the previous phases;
- if the PSP sends an outcome = KO after accepting the pspNotifyPayment vers. 2 the node would respond with KO to signal the discordant outcome;
- By means of the primitive paSendRT, the receipt is sent to the n creditors involved with the payment only if the payment was made, the receipt is an object generated by the pagoPA platform;
- When the creditor receives the receipt, they must close the debt position and consider the notice subject to the payment fully paid.
To manage the errors, refer to Gestione degli errori.
To be able to use the metadata in a correct and standardized manner, a Dizionario dei metadata has been prepared that contains a section dedicated to information about the payment channel present in additionalPaymentInformations of pspNotifyPayment vers. 2.
Tell us what you think
For clarifications on implementation specifications, such as SACI and SANP, you can open an issue on GitHub