/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId}

PUT - paymentRequestPut_v1.6.2

Abstract

Cancellation of a Payment/Transfer Request (PISP)

Description

### Description The PISP sent a Payment/Transfer Request through a POST command. The ASPSP registered the Payment/Transfer Request, updated if necessary the relevant identifiers in order to avoid duplicates and returned the location of the updated Request. The PISP got the Payment/Transfer Request that was updated with the resource identifiers, and eventually the status of the Payment/Transfer Request and the status of the subsequent credit transfer. The PISP requests for the payment cancellation (global cancellation) or for some payment instructions cancellation (partial cancellation) No other modification of the Payment/Transfer Request is allowed. ### Prerequisites - The TPP was 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 previously posted a Payment/Transfer Request which was saved by the ASPSP (cf. § 4.5.3) - The ASPSP answered with a location link to the saved Payment/Transfer Request (cf. § 4.5.4) - The PISP retrieved the saved Payment/Transfer Request (cf. § 4.5.4) - The TPP and the ASPSP successfully processed a mutual check and authentication - The TPP presented its "OAUTH2 Client Credential" access token. - The TPP presented the payment/transfer request. - The PSU was successfully authenticated. ### Business flow #### Payment/Transfer request cancellation circumstances The cancellation of a Payment/Transfer request might be triggered by the PISP upon request of the PSU. It can also be triggered by the PISP itself in case of error or fraud detection. Since the consequence of the cancellation will be a rejection of the Payment/Transfer request globally or limited to some of its instructions, the modification of the payment request will focus on setting the relevant status to the value "CANC". This "CANC" status must however be explained through a reason code that can be set with the following values: | Reason | description | | ------ | ----------- | | DS02 | The PSU himsef/herself ordered the cancellation. | | DUPL | The PISP requested the cancellation for a duplication of a previous Payment/Transfer request | | FRAD | The PISP requested the cancellation for fraudulent origin of the Payment/Transfer request | | TECH | The PISP requested the cancellation for a technical issue on its side | #### Payment/Transfer request cancellation level - Case of a payment with multiple instructions or a standing order, the PISP asks to cancel the whole Payment/Transfer or Standing Order Request including all non-executed payment instructions by setting the [paymentInformationStatus] and the relevant [statusReasonInformation] at payment level. - Case of a payment with multiple instructions, the PISP asks to cancel one or several payment instructions by setting the [transactionStatus] and the relevant [statusReasonInformation] at each relevant instruction level. The cancellation request might need a PSU authentication before committing, especially when the request is PSU-driven. In other cases, the ASPSP may consider that a PSU authentication is irrelevant. In order to meet all possibilities, the cancellation request must nevertheless include: - The specification of the authentication approaches that are supported by the PISP (any combination of "REDIRECT" and "DECOUPLED" values). - In case of possible REDIRECT or DECOUPLED authentication approach, one or two call-back URLs to be used by the ASPSP at the finalisation of the authentication and consent process : - The first call-back URL will be called by the ASPSP if the Transfer Request is processed without any error or rejection by the PSU - The second call-back URL is to be used by the ASPSP in case of processing error or rejection by the PSU. Since this second URL is optional, the PISP might not provide it. In this case, the ASPSP will use the same URL for any processing result. - Both call-back URLS must be used in a TLS-secured request. - In case of possible "DECOUPLED" approach, a PSU identifier that can be processed by the ASPSP for PSU recognition. - The ASPSP saves the updated Payment/Transfer Request and answers to the PISP. The answer embeds - The specification of the chosen authentication approach taking into account both the PISP and the PSU capabilities. - In case of chosen REDIRECT authentication approach, the URL to be used by the PISP for redirecting the PSU in order to perform an authentication. Case of the PSU neither gives nor denies his/her consent, the Cancellation Request shall expire and is then rejected to the PISP. The expiration delay is specified by each ASPSP. If any modification of the payment request other than cancellation is applied by the PISP, the ASPSP must reject the request with HTTP403 without modifying the payment request resource. There is no need for the PISP to post a confirmation of the cancellation request.

Scopes

  • cbpii
  • pisp

Parameters

Authorization (required)
string
header
Access token to be passed as a header
paymentRequestResourceId (required)
string
path
Identification of the Payment Request Resource
paymentRequest (required)
PaymentRequestResource
body
ISO20022 based payment Initiation Request
PSU-IP-Address
string
header
IP address used by the PSU's terminal when connecting to the TPP
PSU-IP-Port
string
header
IP port used by the PSU's terminal when connecting to the TPP
PSU-HTTP-Method
string
header
Http method for the most relevant PSU’s terminal request to the TTP
PSU-Date
string
header
Timestamp of the most relevant PSU’s terminal request to the TTP
PSU-GEO-Location
string
header
Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP
PSU-User-Agent
string
header
"User-Agent" header field sent by the PSU terminal when connecting to the TPP
PSU-Referer
string
header
"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.
PSU-Accept
string
header
"Accept" header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Charset
string
header
"Accept-Charset" header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Encoding
string
header
"Accept-Encoding" header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Language
string
header
"Accept-Language" header field sent by the PSU terminal when connecting to the TPP
PSU-Device-ID
string
header
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
string
header
Digest of the body
Signature (required)
string
header
[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)
string
header
Correlation header to be set in a request and retrieved in the relevant response

Return codes

200 The cancellation request was saved. The ASPSP may have to authenticate the PSU before committing the update.
400 Invalid status value
401 Unauthorized, authentication failure.
403 Forbidden, authentication successful but access to resource is not allowed.
404 Not found, no request available.
405 Method Not Allowed.
406 Not Acceptable.
408 Request Timeout.
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.
503 Service unavailable.

Input

application/json

Output

application/hal+json; charset=utf-8

application/json; charset=utf-8

Available authentification

OAuth 2.0