Send a payment initiation request !

➤ Context   

This call is used to send to the account-holding bank (ASPSP) of a customer (PAO) a request for payment initiation in order to debit the PAO account and to credit the account of the payment service user (PSU) for which the Payment Service Provider (PISP) is connected.

The initiation of single payment in euros is only accepted in our treatments. When submitting the request and if all the fields are correctly formatted, a response (HTPP 201) will be returned.
This response will contain the resourceID of the payment initiation request, as well as the SCA Redirect authentication mode (sole mode available), the consent URL depending on the payer's bank (urlconsent_approval_URL ) and nonce.
 

 SCT Core (immediate, differed, recurring) and Instant Payment PIS operations are available (see restricions the "Limits" use case).

 

➤ Prerequisites

In order to process this request it's needed to fill the eligibility (see "Eligibility" use case), and to get the OAUTH2 access token (see "Retrieve your access token" use case).

 

➤ 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 :

 

➤ Mandated parameters 

Body structure and mandatory fields are described in the STET standard.

The parameters below must be setup at the following values :

  • serviceLevel => "SEPA"
  • amount => shall be setup with min/max as applied on the online banking and they can be different per ASPSP and/or per requested processing  (SCT CORE or INST) and/or customer segment
  • currency => "EUR" => NO international currency transfers available
  • numberOfTransactions => "1" for single payment initiation incl'd for each recurring payment occurrence
  • executionRule => "FWNG" (following = payment execution the next working day)
  • localInstrument shall be setup at « INST » only for SEPA Instant Payment (SCT Inst) :
    • fees can apply depending on ASPSP and customer segment 
    • beneficiary IBAN shall be elligible to accept SCT Inst
  • "Iban", "debtorAccount", "creditorAccount" => a valid normalized IBAN issued by a credit institution / ASPSP
  • chargeBearer field is mandatory (= "SLEV" in euro zone)
  • successfulReportUrl => mandatory parameter for the REDIRECT mode, and it shall contain the redirect URL as well as pkce  (code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) & code_challenge_method =  S256) with "&" separator in the url (/!\ no "?" ) 
  • unsuccessfulReportUrl => if not filled, the data in "successfulReportUrl" will be used 
  • supplementaryData => "REDIRECT"
  • scaHint => field ignored whatever value is set  => NO SCA exemptions
  • categoryPurpose  => mandatory for differenciating funds transfert from merchant-based operations (value "DVPM") to non registered IBAN (value "CASH"), and triggering different business rules and SCA means 
  • requestedExecutionDate => shall be greater than the current PIS request transaction date creationDateTime 
  • creationDateTime => shall be compliant with ISO8601, the three regular expressions allowed are :
    • YYYY-MM-DDTHH:MM:SS.SSS+HH:MM
    • YYYY-MM-DDTHH:MM:SS.SSS+HHMM
    • YYYY-MM-DDTHH:MM:SS.SSS

                          Note : char "Z" at the end means UTC 

                 Example :  2019-11-12T00:00:00.000+02:00

➤ Single SCA UX

If the PISP transmits to the ASPSP all the information necessary to initiate the payment, including the account number/IBAN of the account to be debited, ASPSPs supports a single SCA for a single payment initiation :

  • Debtor IBAN (debtorAccount) only : a screen for PSU identification is still requested before the unique SCA (for dynamic linking)
  • Debtor IBAN (debtorAccount) + PSU identification : no need ti identify the PSU before the unique SCA (for dynamic linking)

 

➤ Cut-off for Immediate SCT Core 

The CUT-OFF time means the deadline for fund transfer execution, and takes into account :

  • internal processing (execution and clearing on the samle day)
  • CUT-OFF from various interbank schemes (incl'd clearing house, see TARGET2 banking business days calendar and SCT rulebook)

In case of SEPA CREDIT TRANSFER (SCT), there is a maximum execution time : originator Banks are obliged to ensure that the amount of the SEPA Credit Transfer is credited to the account of the Beneficiary Bank within one Banking Business Day following the point in time of receipt of the Credit Transfer Instruction in accordance with the provisions of the Payment Services Directive. A shorter execution time for SEPA Credit Transfers, knowing that operations may not be open for business on certain days of the year for the purpose of executing SEPA Credit Transfers.

It is not authorized to postpone the initial PSU order date except if it has been overriden. Execution time will be then reported to the following authorized date if it not a bank holiday. The execution process is triggered depending on the full timestamp of the PIS request.

For this ASPSP, CUT-OFF for SCT Core is fixed at 01:30 pm continental time (GMT+2 in summer, GMT+1 in winter).

 

➤ Differed and recurrent SCT Core

The execution date (data requestedExecutionDate) for a differed SCT Core (or the first occurrence of a recurrent SCT Core) shall be setup at +72 hours like on online banking environment, otherwise it will be rejected. 

For recurrent SCT, allowed frequencies (data frequency) are the following ones : 

  • weekly 
  • every two weeks
  • monthy
  • quaterly
  • every six months 
  • yearly

 

➤ Creditor IBAN control

 A temporary control for NOT allowing PISP initiaitions has been added since December 7th, 2020 (alignment on direct access security features for funds transfer) :

  • If the Creditor IBAN is NOT included in preregistered list done through the direct access 
  • AND if the field categoryPurpose = "CASH"
  • AND if the SCA is NOT peformed by the PSU using the most secure authentication means (e.g. Sécur'Pass for retail PSU)

 

➤ Error codes    

Error type

HTTP code

Description

Reason

Generic, bad structure

400

Bad request

error code : FF01
message : RJCT

Wrong format for BIC

400

Bad request

error code : FF01
message : RJCT
error : the field creditorAgent.bicFi bicFi-Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362

Wrong format for serviceLevel

400

Bad request

error code : FF01
message : RJCT
error : value not one of declared Enum instance names: [SEPA, NURG]

Wrong format for chargeBearer different from SLEV

400

Bad request

error code: FF01
message: RJCT
error: value not one of declared Enum instance names: [SLEV]

Wrong format for schemeName

400

Bad request

error code: FF01
message : RJCT
error : the field creditor.privateId.schemeName schemeName-Possible values BANK,COID,SREN,DSRET,NIDN,OAUT,CPAN
Wrong format for purpose 400 Bad request error code: FF01
message: RJCT
error: value not one of declared Enum instance names: [TRPT, CASH, CPKC, ACCT, COMC]

Wrong format for categoryPurpose

400

Bad request

error code: FF01
message: RJCT
error: value not one of declared Enum instance names: [CASH, DVPM]

Wrong access token, authentication issue

403

Forbidden

  

Unknown request resource

404

Not Found

  

Wrong request, or request out of authorized scope

405

Method not allowed

  

Generic message

500

Internal server error

  

Duplicate request

500

Internal server error

error : Database insertion problem, duplicate unique key