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

PUT - paymentRequestPut

Abstract

Modification 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 might have been updated with the resource identifiers, the status of the Payment/Transfer Request and the status of the subsequent credit transfer.
The PISP request for the payment cancellation or for some payment instructions 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.3).
  • 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

the following cases can be applied:
  • 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] to "RJCT" and the relevant [statusReasonInformation] to "DS02" at payment level.
  • Case of a payment with multiple instructions, the PISP asks to cancel one or several payment instructions by setting the [transactionStatus] to "RJCT" and the relevant [statusReasonInformation] to "DS02" at each relevant instruction level.
Since the modification request needs a PSU authentication before committing, the modification request includes:
  • The specification of the authentication approaches that are supported by the PISP (any combination of "REDIRECT", "EMBEDDED" 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, including mutual authentication based on each party’s TLS certificate.
  • In case of possible "EMBEDDED" or "DECOUPLED" approaches, 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.

    Authentication flows for both use cases

    Redirect authentication approach

    When the chosen authentication approach within the ASPSP answers is set to "REDIRECT":
    • The PISP redirects the PSU to the ASPSP which authenticates the PSU
    • The ASPSP asks the PSU to give (or deny) his/her consent to the Payment Request
    • The PSU chooses or confirms which of his/her accounts shall be used by the ASPSP for the future Credit Transfer.
    • The ASPSP is then able to initiate the subsequent Credit Transfer
    • The ASPSP redirects the PSU to the PISP using one of the call-back URLs provided within the posted Payment Request
    If the PSU neither gives nor denies his/her consent, the Payment Request shall expire and is then rejected to the PISP. The expiration delay is specified by each ASPSP.

    Decoupled authentication approach

    When the chosen authentication approach is "DECOUPLED":
    • Based on the PSU identifier provided within the Payment Request by the PISP, the ASPSP gives the PSU with the Payment Request details and challenges the PSU for a Strong Customer Authentication on a decoupled device or application.
    • The PSU chooses or confirms which of his/her accounts shall be used by the ASPSP for the future Credit Transfer.
    • The ASPSP is then able to initiate the subsequent Credit Transfer
    • The ASPSP notifies the PISP about the finalisation of the authentication and consent process by using one of the call-back URLs provided within the posted Payment Request
    If the PSU neither gives nor denies his/her consent, the Payment Request shall expire and is then rejected to the PISP. The expiration delay is specified by each ASPSP.

    Embedded authentication approach

    When the chosen authentication approach within the ASPSP answers is set to "EMBEDDED":
    • The TPP informs the PSU that a challenge is needed for completing the Payment Request processing. This challenge will be one of the following:
      • A One-Time-Password sent by the ASPSP to the PSU on a separate device or application.
      • A response computed by a specific device on base of a challenge sent by the ASPSP to the PSU on a separate device or application.
    • The PSU unlock the device or application through a "knowledge factor" and/or an "inherence factor" (biometric), retrieves the Payment Request details and processes the data sent by the ASPSP;
    • The PSU might choose or confirm which of his/her accounts shall be used by the ASPSP for the future Credit Transfer when the device or application allows it.
    • When agreeing the Payment Request, the PSU enters the resulting authentication factor through the PISP interface which will forward it to the ASPSP through a confirmation request (cf. § 4.7)
    Case of the PSU neither gives nor denies his/her consent, the Payment Request shall expire and is then rejected to the PISP. The expiration delay is specified by each ASPSP.

    Scopes

    • pisp

    Parameters

    paymentRequest (required)
    PaymentRequestResource
    body
    ISO20022 based payment Initiation Request
    Authorization (required)
    string
    header
    Access token to be passed as a header
    paymentRequestResourceId (required)
    string
    path
    Identification of the Payment Request Resource
    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 (cf. 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 modification request has been saved. The ASPSP must authenticate the PSU before committing the update.
    400 Bad Request
    401 Unauthorized
    403 Forbidden
    404 Not Found
    405 Method Not Allowed
    406 Not Acceptable
    408 Request Timeout
    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