/stet/psd2/v1.4.2/payment-requests

POST - paymentRequestsPost_v1.4.2

Résumé

Payment request initiation (PISP)

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 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 Having at the same time multiple beneficiaries and multiple execution date might not be a relevant business case, although it is technically allowed. Each implementation will have to specify which business use cases are actually supported. 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 Payment request can rely for execution on different payment instruments: - SEPA Credit Transfer (SCT) - Domestic Credit Transfer in a non-Euro-currency - International payment The following table indicates how to use the different fields, depending on the payment instrument: | Structure | SEPA payments | Domestic payments in non-euro currency | International payments | | --------- | ------------- | -------------------------------------- | ---------------------- | | PaymentTypeInformation/InstructionPriority (payment level) | "HIGH" for high-priority SCT, "NORM" for other SCT, Ignored for SCTInst | "HIGH" for high-priority CT, "NORM" or ignored for other CT | "HIGH" for high-priority payments, "NORM" or ignored for other payments | | PaymentTypeInformation/ServiceLevel (payment level) | "SEPA" for SCT and SCTInst | ignored | ignored | | PaymentTypeInformation/CategoryPurpose (payment level) | "CASH" for transfer request, "DVPM" for payment request on behalf of a merchant || "CORT" for generic international payments, "INTC" for transfers between two branches within the same company, "TREA" for treasury transfers | | PaymentTypeInformation/LocalInstrument (payment level) | "INST" pour les SCTInst, otherwise ignored | Ignored or valued with ISO20022 external code || | RequestedExecutionDate (either at payment or transaction level) | Mandatory (indicates the date on debit on the ordering party account) ||| | EndToEndIdentification (at transaction level) | Mandatory | Optional || | UltimateDebtor (at transaction level) | Optional ||| | UltimateCreditor (at transaction level) | Optional ||| | InstructedAmount (at transaction level) | Mandatory || Mandatory and exclusive use of one of these structures | | EquivalentAmount (at transaction level) | Not used || Mandatory and exclusive use of one of these structures | | ChargeBearer (at transaction level) | "SLEV" for SCT and SCTInst | "SLEV" or "SHAR" | "CRED", "DEBT" or "SHAR" | | Purpose (at transaction level) | Optional ||| | RegulatoryReportingCode (at transaction level) | Not used | Mandatory (possibly multiple values) | | InstructionForCreditorAgent (at transaction level) | Not used || Optional (possibly multiple values) | | RemittanceInformation | Mandatory. Structured or unstructured, depending on the local rules and constraints ||| | Debtor (at payment level) | Mandatory, 2 address lines only | Mandatory, 4 address lines only | Mandatory. Complete strustured address can be used. | | DebtorAccount (at payment level) | Optional | Optional. Account currency may be specified || | DebtorAgent (at payment level) | Optional ||| | Creditor (either at payment or transaction level) | Mandatory, 2 address lines only | Mandatory, 4 address lines only | Mandatory. Complete strustured address can be used. Date and place of birth must be specified | | CreditorAccount (either at payment or transaction level) | Mandatory | Mandatory. Account currency may be specified || | CreditorAgent (either at payment or transaction level) | Optional ||| | ClearingSystemId et ClearingSystemMemberId (either at payment or transaction level) | Not used || Optional | | IntermediaryAgent et IntermediaryAgentAccount (either at payment or transaction level) | Not used | Optional || - 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 and the ASPSP have successfully processed a mutual check and authentication - The TPP has presented its "OAUTH2 Client Credential" access token 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 for the ASPSP to check the existence 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. 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. 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

Scopes

  • pisp

Paramètres

Authorization (required)
string
header
Access token to be passed as a header
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
ui_locales
string
query
End-User's preferred languages and scripts for the user interface, represented as a space-separated list of BCP47 [RFC5646] language tag values, ordered by preference.

Codes retour

201 The request has been created as a resource. The ASPSP must authenticate the PSU.
400 Invalid status value
401 Unauthorized, authentication failure.
403 Forbidden, authentication successful but access to resource is not allowed.
405 Method Not Allowed.
406 Not Acceptable.
408 Request Timeout.
429 Too many requests.
500 Internal server error.
503 Service unavailable.

Entrées

application/json

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0