Payment request initiation (PISP)

API: Identifier assigned by the ASPSP for further use of the created resource through API calls. The API client cannot set or modify the value of this field. Since this value can be exchanged between the server and the client as an URL element or for support information, it must not contain sensitive value such as personal or business data. However it is the duty of each ASPSP to perform its own risk analysis on this topic.

ISO20022: Reference assigned by a sending party to unambiguously identify the payment information block within the message. API: This field is a clue for idempotency check by the ASPSP in order to avoid duplicate SCA or payment execution. However the ASPSP may use other mechanisms.

Identifies whether a single entry per individual transaction or a batch entry for the sum of the amounts of all transactions within the group of a message is requested. Meaning When True: Identifies that a batch entry for the sum of the amounts of all transactions in the batch or message is requested. Meaning When False: Identifies that a single entry for each of the transactions in the batch or message is requested. Default value: each ASPSP must be able to specify its own default value.

ISO20022: Date and time at which a (group of) payment instruction(s) was created by the instructing party.

ISO20022: Number of individual transactions contained in the message. API: Each ASPSP will specify a maximum value for this field taking into accounts its specificities about payment request handling

indicator that the debtor account can be changed in the payment request by the ASPSP if needed

• true: debtor account can be changed (default value)
• false: debtor account cannot be changed

indicator that the charge handling can be changed in the payment request by the ASPSP if needed

• true: charge handling can be changed (default value)
• false: charge handling cannot be changed

Indicator that the requested instant SEPA Credit Transfer method can be downgraded by the ASPSP into a plain-vanilla SEPA Credit Transfer, when Instant SCT cannot apply or is refused by the PSU. Eventually, it is up to the ASPSP to downgrade or reject the payment. In case of a downgrade, the ASPSP will have to update de relevant field [LocalInstrument] and remove the “INST” value in order to keep the PISP informed.

• true: payment method can be downgraded
• false: payment method cannot be downgraded (default value)

ISO20022: Specifies which party/parties will bear the charges associated with the processing of the payment transaction. The following values are allowed:

ISO20022: Specifies the status of the payment information. API: Mandatory. The following values are allowed to provide the status of the Payment Request

Code	Name	Description
ACCO	AcceptedCustomerCOnfirmed	The customer, during his/her authentication, has confirmed the payment request.
ACCP	AcceptedCustomerProfile	Preceding check of technical validation was successful. Customer profile check was also successful.
ACSC	AcceptedSettlementCompleted	Settlement on the debtor's account was completed. In the case of SCTInst, this status must not been set by the debtor's Bank before the reception of the positive confirmation.
ACSP	AcceptedSettlementInProcess	All preceding checks such as technical validation and customer profile were successful. Dynamic risk assessment is now also successful and therefore the Payment Request was 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	Cancelled	Payment initiation was successfully cancelled after having received a request for cancellation.
PART	PartiallyAccepted	A number of transactions were accepted, whereas another number of transactions have not yet achieved 'accepted' status.
PATC	PartiallyAcceptedTechnicalCorrect	Payment initiation needs multiple authentications, where some but not yet all were performed. Syntactical and semantical validations are successful.
RCVD	Received	Payment initiation was 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 was rejected.

ISO20022: Provides detailed information on the status reason.

API: Can only be used in case the status is equal to "RJCT" or "CANC". Only the following values are allowed:

Indicator that the payment can be covered or not by the funds available on the relevant account

• true: payment is covered
• false: payment is not covered This indicator must be provided by the ASPSP when the Booking Information is present and set to "False". This indicator will not be provided if the Booking Information is absent or set to "True".

Indicator that the payment can be immediately booked or not

• true: payment is booked
• false: payment is not booked Booking a transaction means that the funds required by this transaction are immediatly reserved and that a subsequent transaction will not interfere with the proper execution of the payment. However, usual fraud detection mechanisms might still be triggered and result as a rejection of the payment. This indicator must be provided when the relevant Credit Transfer will be executed as soon as possible but not as an instant payment. This indicator is irrelevant and will not be provided for delayed payments. This indicator is only relevant for the first occurrence of a standing order when this occurrence is not delayed and will be executed as soon as possible.

Case the Information System cannot handle this immediate booking, the ASPSP will have to provide the funds availability information.

Authentication approaches that can be applied. REDIRECT: the PSU is redirected by the TPP to the ASPSP which processes identification and authentication DECOUPLED: the TPP identifies the PSU and forwards the identification to the ASPSP which processes the authentication through a decoupled device NONE: there is no need for the PSU to authenticate

Challenge to be sent in order to avoid replay of the authentication process.