POST - paymentRequestOConfirmationPost_v1.4.2
Confirmation of a payment request or a modification request using an OAUTH2 Authorization code grant (PISP)
The PISP confirms one of the following requests or modifications: - payment request on behalf of a merchant - transfer request on behalf of the account's owner - standing-order request on behalf of the account's owner The ASPSP answers with a status of the relevant request and the subsequent Credit Transfer. - The TPP has been registered by the Registration Authority for the PISP role - The TPP was provided with an OAUTH2 "Client Credential" access token by the ASPSP (cf. § 3.4.2). - The TPP has previously posted a Request which has been saved by the ASPSP (cf. § 4.5.3) - The ASPSP has answered with a location link to the saved Payment Request (cf. § 4.5.4) - The TPP has retrieved the saved request in order to get the relevant resource Ids (cf. § 4.6). - The PSU has been authenticated by the ASPSP through an OAUTH2 authorization code grant flow (REDIRECT approach) and the PISP got the relevant token - The TPP and the ASPSP have successfully processed a mutual check and authentication - The TPP has presented its "OAUTH2 Authorization Code" access token Once the PSU has been authenticated through an OAUTH2 authorization code grant flow (REDIRECT approach), it is the due to the PISP to confirm the Request to the ASPSP in order to complete the process flow. The ASPSP must wait for confirmation before executing the subsequent Credit Tranfer.
|Authorization (required)|| |
Access token to be passed as a header
|paymentRequestResourceId (required)|| |
Identification of the Payment Request Resource
|confirmationRequest (required)|| |
Click to set as parameter value
Parameters needed for confirmation of the Payment Request, especially in "EMBEDDED-1-FACTOR" approach Even though there is no parameter, a Json (void) body structure must be provided.
IP address used by the PSU's terminal when connecting to the TPP
IP port used by the PSU's terminal when connecting to the TPP
Http method for the most relevant PSU’s terminal request to the TTP
Timestamp of the most relevant PSU’s terminal request to the TTP
Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP
"User-Agent" header field sent by the PSU terminal when connecting to the TPP
"Referer" header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that "referer" (incorrect spelling) is to be used. The correct spelling "referrer" can be used but might not be understood.
"Accept" header field sent by the PSU terminal when connecting to the TPP
"Accept-Charset" header field sent by the PSU terminal when connecting to the TPP
"Accept-Encoding" header field sent by the PSU terminal when connecting to the TPP
"Accept-Language" header field sent by the PSU terminal when connecting to the TPP
UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device.
Digest of the body
|Signature (required)|| |
[http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate.
|X-Request-ID (required)|| |
Correlation header to be set in a request and retrieved in the relevant response
|200||retrieval of the Payment Request enriched with the status report|
|400||Invalid status value|
|401||Unauthorized, authentication failure.|
|403||Forbidden, authentication successful but access to resource is not allowed.|
|405||Method Not Allowed.|
|409||Conflict. The request could not be completed due to a conflict with the current state of the target resource.|
|429||Too many requests.|
|500||Internal server error.|