Payments at the EC frontend in asynchronous mode

When the EC frontend receives the request to pay one or more notices, before sending the request to Checkout by means of a redirect, it loads the relative debt position(s) by invoking the createDebtPosition api exposed by the GPD core component;

in order to create, publish and set the debt positions to the VALID state with a single invocation to the GPD core component, it is suggested to set the query parameter toPublish=true and the field of the debt position validityDate=null;

at this point, the debt position(s) are present in the PagoPA debt position service and they are in the correct state to be paid;

Checkout, based on the number of notices received, requests the node to activate the n payments, in turn the payment node forwards the requests to the GPD payments component, which will respond to the primitive paGetPaymentV2 on behalf of the EC;

the payment process proceeds unvaried as described on the page Payment at the EC frontend up to the moment of invoking the primitive paSendRTV2, which in the case of asynchronous integration is forwarded to the GPD payments component and possibly to the configured broadcast stations;

the direct EC or the intermediary must make an endpoint available that is compliant with the specifications indicated in the Connectivity section, and where the paSendRTV2 service can be exposed. This allows PagoPA S.p.A. to configure a broadcast station on which it sends the receipts in real time as the payments are completed with a positive result. This configuration helps the creditor receive the receipts in push mode, without using polling mechanisms toward the APIs exposed by the component GPD-Core. The APIs for recovering the receipts can be used in particular cases, such as for a technical problem when receiving one or more receipts via the broadcast station;

when the GPD-Payments component receives the receipt, it closes the debt position.