/stet/psd2/v1/payment-requests

POST - paymentRequestsPost

Abstract

Payment request initiation (PISP)

Description

Description

The following use cases can be applied:
  • 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

Data content

A payment request or a transfer request might embed several payment instructions having
  • one single execution date or multiple execution dates
    • case of one single execution date, this date must be set at the payment level
    • case of multiple execution dates, those dates must be set at each payment instruction level
  • one single beneficiary or multiple beneficiaries
    • case of one single beneficiary, this beneficiary must be set at the payment level
    • case of multiple beneficiaries, those beneficiaries must be set at each payment instruction level
A standing order request must embed one single payment instruction and must address one single beneficiary.
  • The beneficiary must be set at the payment level
  • The standing order specific characteristics (start date, periodicity...) must be set at the instruction level

Prerequisites for all use cases

  • 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.3).
  • The TPP and the ASPSP have successfully processed a mutual check and authentication
  • The TPP has presented its "OAUTH2 Client Credential" access token

Business flow

Payment Request use case
The PISP forwards a payment request on behalf of a merchant.
The PSU buys some goods or services on an e-commerce website held by a merchant. Among other payment method, the merchant suggests the use of a PISP service. As there is obviously a contract between the merchant and the PISP, there is no need of such a contract between the PSU and this PISP to initiate the process.
Case of the PSU that chooses to use the PISP service:
  • The merchant forwards the requested payment characteristics to the PISP and redirects the PSU to the PISP portal.
  • The PISP requests from the PSU which ASPSP will be used.
  • The PISP prepares the Payment Request and sends this request to the ASPSP.
  • The Request can embed several payment instructions having different requested execution date.
  • The beneficiary, as being the merchant, is set at the payment level.
Transfer Request use case
The PISP forwards a transfer request on behalf of the owner of the account.
  • The PSU provides the PISP with all information needed for the transfer.
  • The PISP prepares the Transfer Request and sends this request to the relevant ASPSP that holds the debtor account.
  • The Request can embed several payment instructions having different beneficiaries.
  • The requested execution date, as being the same for all instructions, is set at the payment level.
Standing Order Request use case
The PISP forwards a Standing Order request on behalf of the owner of the account.
  • The PSU provides the PISP with all information needed for the Standing Order.
  • The PISP prepares the Standing Order Request and sends this request to the relevant ASPSP that holds the debtor account.
  • The Request embeds one single payment instruction with
    • The requested execution date of the first occurrence
    • The requested execution frequency of the payment in order to compute further execution dates
    • An execution rule to handle cases when the computed execution dates cannot be processed (e.g. bank holydays)
    • An optional end date for closing the standing Order

Authentication flows for all use cases

As the request posted by the PISP to the ASPSP needs a PSU authentication before execution, this request will include:
  • 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 Payment 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 "EMBEDDED" or "DECOUPLED" approaches, the PSU identifier that can be processed by the ASPSP for PSU recognition must have been set within the request body [debtor] structure.
The ASPSP saves the request and answers to the PISP. The answer embeds:
  • A location link of the saved Request that will be further used to retrieve the Request and its status information.
  • 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 a authentication.
Case of the PSU neither gives nor denies his/her consent, the Request shall expire and is then rejected to the PISP. The expiration delay is specified by each ASPSP.
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
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
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)

Scopes

  • pisp

Parameters

paymentRequest (required)
PaymentRequestResource
body
ISO20022 based payment Initiation Request
Authorization (required)
string
header
Access token to be passed as a header
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

201 The request has been created as a resource. The ASPSP must authenticate the PSU.
400 Bad Request
401 Unauthorized
403 Forbidden
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