DevPortalPagoPA




Table of contents

Data model

When describing the interfaces, reference will be made to some entities whose relationships are shown by the following diagram
  • Debt position: the parent entity for which the creditor wants to receive payments via the platform. It is identified by the IUPD (Debt Position Unique Identifier) and is comprised of the following:
    • one or more payment options (e.g. one-time payment, installment payment, etc.), more information can be found in payment options;
    • each payment option is comprised of one or more installments, this entity presents all the information that identifies the payment notice (e.g. the NAV and the IUV), each installment is associated with 1 to 5 transfers.
  • Payment notice: represents the notification (paper or digital) to the citizen of each payment that is due.
  • Payment: describes in detail the payment transaction correlated to a notice and contains collection and credit information.
  • Receipt: it describes the result of a payment and contains the details of the collection and the indication of the credit, it also contains the reference to the payment notice.
  • Reporting flow: it details the repayment made towards the current accounts of a creditor by a PSP and contains the list of all the payments.

Business data structures

The payment is an object generated by the creditor, managed by the pagoPA platform and forwarded to the PSP; the creditor provides this object to the pagoPA platform with the response to paGetPayment, the pagoPA platform supplies this object to the PSP with the response to activatePaymentNotice; the payment object provided to the PSP contains a subject of data sent by the creditor to the pagoPA platform.
The receipt is an object generated by the pagoPA platform based on the data received form the response to paGetPayment (from the creditor) and from the sendPaymentOutcome (from the PSP); it is sent to the n creditors involved with the payment by means of the primitive paSendRT; the receipt object is sent to the EC only if the payment was made.
The reporting flow contains the information that must be made available to the creditor to perform the payment reconciliation operations, this flow must be made available to the concerned parties by the PSP who performed the payment operation by and no later than 24 hours from the second business day following the receipt of the payment order (D+2). The PSP send each individual reporting flow to the pagoPA platform via the primitive nodoInviaFlussoRendicontazione; to receive the reporting flows from the creditor, the primitives to use are the nodoChiediElencoFlussiRendicontazione, to have the list of the available flows, and the nodoChiediFlussoRendicontazione to download a specific flow.
![](../.gitbook/assets/flussiRendicontazione (1).png)

Support data structures

The Information Data Catalog is the data structure through which, for the purpose of transparency of the transactions, the payment-SPC node registers the payment condition data for the PSP (maximum service costs, web pages with a description of the services, etc.), this catalog is updated daily by the PSPs directly.
The Service catalog is used by the PSPs to obtain details about particular services offered by each creditor, to be able to offer the spontaneous payment (spontaneous-payment-via-psp), this structure can be taken via the primitive nodoChiediCatalogoServizi.
![](../.gitbook/assets/image (48).png)

Need help?

Open a ticket using the dedicated function within your Reserved Area

Tell us what you think

For clarifications on implementation specifications, such as SACI and SANP, you can open an issue on GitHub