Retrieve a payment initiation request
➤ Use case
This method allows the PISP to obtain the status of a payment initiation request previously sent to the ASPSP for a given PSU through a POST /paymentRequests request.
➤ Prerequisites
In order to process this request some eligibility prerequisites are needed, like to get an OAUTH2 access token beforehand (see "Get your token" use case).
The TPP has already sent a request that has been saved by the ASPSP and to which the ASPSP responded with a location link to the saved payment/transfer request.
➤ Request
The entry point depends on the bank code <bkcode>.
You need to insert the same <bkcode> parameter as the one used for requesting the access token.
As a reminder, the list of our banking institutions and the possible values of <bkcode> are specified in the "Limits" use case.
For example, the url to be used to access to a PSU from the Caisse d'Epargne Ile de France is :
- GET https://www.<bkcode>.live.api.89c3.com/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId}
➤ Mandatory or facultative body parameters
Mandatory parameter paymentRequestResourceId : Identification of the payment request resource.
➤ Returned result
When submitting the request and if all the data is correctly formatted, a response HTTP 200 will be returned.
This response will contain the payment initiation data enriched with the status of the initiation request and the associated payment.
The possible values for the status of the payment request are as follows (see STET specifications) :
| Code | Description |
| ACCO | AcceptedCustomerConfirmed : the customer has confirmed the payment request during his/her authentication. |
| ACCP | AcceptedCustomerProfile : Preceding check of technical validation was successful. Customer profile check was also successful. |
| ACSC | AcceptedSettlementCompleted : Settlement on the debtor's account has been completed. |
| ACSP | AcceptedSettlementInProcess : All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution. |
| ACTC | AcceptedTechnicalValidation : Authentication and syntactical and semantical validation are successful. |
| ACWC | AcceptedWithChange : Instruction is accepted but a change will be made, such as date or remittance not sent. |
| ACWP | AcceptedWithoutPosting : Payment instruction included in the credit transfer is accepted without being posted to the creditor customer’s account. |
| CANC | Payment initiation has been successfully cancelled after having received a request for cancellation. |
| PART | PartiallyAccepted : A number of transactions have been accepted, whereas another number of transactions have not yet achieved 'accepted' status. |
| PATC | PartiallyAcceptedTechnicalCorrect |
| RCVD | Received : Payment initiation has been received by the receiving agent. |
| PDNG | Pending : Payment request or individual transaction included in the payment request is pending. Further checks and status update will be performed. |
| RJCT | Rejected : Payment request has been rejected. |
The following table shows the possible values for the status of the payment initiation and the associated payment transaction :
| Processing an initiation containing a payment | Result | paymentInformationStatus value | creditTransferTransactionStatus value |
| Check and record the initiation request | OK | ACTC | - |
| KO | RJTC | - | |
| Consent | OK | ACCP | - |
| KO | RJCT | - | |
| Request for payment execution | OK | ACSP | PDNG if executed on the same day |
| OK | ACSP | ACSP | |
| KO | RJCT | RJCT | |
| If the PSU doesn't perform any action within 30 mns starting form the payment initiation reception | - | RJCT (NOAS reason) | RJCT (NOAS reason) |
| Payment execution before clearing | - | ACSP | ACSP |
| Single payment execution after clearing | OK | ACSC | ACSC |
| KO | RJCT | RJCT | |
| Recurrent payment execution after clearing | OK | ACSP | ACSP |
| KO | RJCT | RJCT |
The following table shows the possible values following a status of the payment initiation cancellation :
| Processing an initiation containing a payment | Result | paymentInformationStatus value | creditTransferTransactionStatus value |
| Before cancellation request | - | ACTC/ACCP/ACSP | -/PDNG (ifpaymentInformationStatus = ACSP) |
| Control of the cancellation request | OK | RJCT/RJCT/ACSP | -/PDNG (ifpaymentInformationStatus = ACSP) |
| KO | ACTC/ACCP/ACSP | -/PDNG (ifpaymentInformationStatus = ACSP) | |
| PSU Consent | OK | ACSP | PDNG |
| KO | ACSP | PDNG | |
| Execution of the cancellation | OK | CANC (DS02, DUPL, FRAD, TECH) | CANC (DS02, DUPL, FRAD, TECH) |
| KO | ACSP | PDNG |
➤ Availability of the debitor IBAN
The debitor IBAN is returned in the ASPSP response even if this data was not included in the PIS request sent by the TPP.
➤ Error codes
Error type | HTTP code | Description | Reason |
Bad access token, authentication problem | 403 | Forbidden | |
Unknown request resource | 404 | Not Found | Unknown ressource |
Bad request or request outside the authorized scope | 405 | Method not allowed | |
Generic message | 500 | Internal server error | |
Duplicate query | 500 | Internal server error | error : Database insertion problem, duplicate unique key |