Banque populaire – Initiation de paiement – (Norme STET V1.6.2)

Initier un paiement

Un de nos clients effectue une transaction sur un site d’e-commerce ou souhaite effectuer un virement ou un transfert unitaire ou multiple.

Via cette API « Initiation de paiement » mise à disposition par notre banque, vous pouvez soumettre en temps réel une demande d’initiation du paiement.

Le client connecté va être sollicité par sa banque pour valider l’opération.

Dans le cadre d’un parcours classique :

1. Le PSU s’identifie et s’authentifie ;
2. Puis, il sélectionne le compte de paiement disposant d’un solde minute suffisant pour le montant de l’opération ;
3. Enfin, la banque scelle l’opération après que le client se soit à nouveau authentifié fortement pour valider l’opération.

Dans le cadre d’un parcours fluide, les données du compte débiteur sont transmises dans la requête d’initiation de paiement :

1. Le PSU s’identifie si son identifiant n’est pas transmis dans la requête ;
2. Puis, il vérifie les informations de l’opération ;
3. Enfin, la banque scelle l’opération après que le client se soit authentifié fortement pour valider l’opération.

Cette API ne peut être consommée que par des prestataires ayant le rôle d’initiateurs de paiement (« PISP »), ce prérequis étant décrit dans voir la rubrique « Éligibilité« .

Une fois ce prérequis rempli, le processus global est le suivant :

1- Le client souhaite utiliser vos services afin de réaliser un virement ou un transfert unitaire ou multiple, ou alors il sélectionne votre service lorsqu’il est sollicité par un e-commerçant pour régler son achat sur le site du e-commerçant. Il vous précise la banque dans laquelle il est domicilié à travers vos interfaces.

2- Lors du premier échange avec les infrastructures du teneur de compte, vous allez faire une demande de jeton d’autorisation. Le principe de base est, qu’en tant que TPP PISP, vous devez obtenir ce jeton AVANT de consommer l’API. Ce jeton est généré par le teneur de compte (ASPSP) APRES avoir vous avoir identifié.

En tant que teneur de compte, nous allons :

• Vérifier vos certificats et agréments.

Pour cette API, il n’est pas nécessaire que nous identifiions et authentifions fortement le client afin de récupérer son consentement et de générer le jeton d’accès.

3- Si nous avons pu vérifier votre identité et vos agréments, vous pourrez ensuite récupérer un jeton d’accès OAUTH2 via des échanges sécurisés avec la plateforme BPCE API (voir la rubrique « Vue d’ensemble » > « Récupérer votre jeton« ).

4- En présentant ce jeton d’autorisation valable uniquement pour cette opération, vous pourrez alors consommer l’API « initiation de paiement » afin :

• D’initier le paiement (voir la rubrique « Cas d’usage » > « Initier un paiement« ) ;
• De récupérer le statut de l’initiation de paiement (voir la rubrique « Cas d’usage » > « Récupérer le statut d’une initiation de paiement« ) ;
• De modifier une initiation de paiement (voir la rubrique « Cas d’usage » > « Annuler une initiation de paiement« )
• De confirmer une initiation de paiement (voir la rubrique « Cas d’usage » > « Confirmer une initiation de paiement – méthode confirmation« ).

Consommer l'API

La description des services proposés ci-après n’est que purement fonctionnelle. Les aspects techniques sont répertoriés dans les sections « Cas d’usage » qui sont plus détaillées.

Vous devez aussi être familier avec la terminologie DSP2 et les abréviations utilisées. Vous pouvez également utiliser la foire aux questions (FAQ), l’assistant virtuel ou le glossaire.

Prérequis

En tant que TPP, vous devez être accrédité par l’autorité de contrôle prudentiel et de résolution (ACPR) pour le rôle d’initiateur de paiement (« PISP »).

Pour accéder aux services de l’API d’initiation de paiement, vous devez récupérer un jeton d’accès OAUTH2 délivré par l’établissement bancaire du PSU en l’interrogeant avec vos credentials.

A ce titre, vous devez vous authentifier mutuellement avec le teneur de compte (ASPSP) par échange de certificats eIDAS QWAC.

Vous présenterez ensuite votre jeton d’accès OAUTH2 pour pouvoir consommer les services de l’API d’initiation de paiement.

Initier un paiement

Il existe deux cas d’utilisation de l’API d’initiation de paiement :

1) Le PISP fait une demande de paiement pour le compte d’un commerçant : le client PSU achète des biens ou des services sur un site e-commerce (cf. haut du schéma ci-après).

Il existe un contrat entre le e-commerçant et le PISP.

Le e-commerçant transmet les caractéristiques du paiement demandées au PISP et redirige le client PSU vers le portail du PISP.

Le PISP interroge le client PSU pour connaître l’établissement bancaire à partir duquel il souhaite débiter son compte. Puis il prépare la demande de paiement et l’envoie à l’établissement bancaire du client.

Le bénéficiaire (= le e-commerçant) est indiqué dans le paiement.

2) Le PISP fait une demande de virement unitaire ou multiple pour le compte du client PSU titulaire du compte. Le PSU fournit au PISP les informations nécessaires au transfert (cf. bas du schéma ci-après).

Le PISP interroge le client PSU afin de connaître l’établissement bancaire à partir duquel il souhaite débiter son compte. Puis il prépare la demande de paiement et l’envoie à l’établissement bancaire du PSU.

voir les spécifications STET V1.6.2 / Part I / section 3.4.5.3 page 50

Vous transmettez la requête d’initiation de paiement via la méthode POST /payment-requests (cf. rubrique « Cas d’usage » > « Initier un paiement« ).

La méthode d’authentification supportée par l’établissement bancaire est le mode REDIRECT renforcé :

1) Le PSU est redirigé vers un écran d’identification proposé par son établissement bancaire et dans lequel il saisira son identifiant de banque à distance.

2) Le PSU est redirigé vers un premier écran d’authentification forte proposé par son établissement bancaire pour valider son identité.

La cinématique de cette étape dépend de la méthode d’authentification forte mise à disposition du PSU par l’établissement bancaire (SMS OTP, Secur’pass, etc.).

Elle dépend aussi de l’équipement du PSU sur lequel tourne l’application du PISP utilisée par le PSU (PC ou mobile/tablette).

3) Le PSU est redirigé vers un écran de sélection de son compte à débiter proposé par son établissement bancaire.

4) Le PSU sélectionne et valide le compte à débiter.

5) Le PSU est redirigé vers un second écran d’authentification forte proposé par son établissement pour valider son paiement.

La cinématique de cette étape dépend de la méthode d’authentification forte mise à disposition du PSU par l’établissement bancaire (SMS OTP, Secur’pass, etc.).

Elle dépend aussi de l’équipement bancaire du PSU sur lequel tourne l’application du PSU (PC ou mobile/tablette).

6) Le PSU est redirigé vers un écran de confirmation de l’opération proposé par son établissement bancaire.

7) Le PSU est redirigé vers l’application du PISP.

8) Vous transmettez la requête de confirmation de l’initiation du paiement via la méthode POST /payment-requests/{paymentRequestResourceId}/confirmation (cf. rubrique « Cas d’usage » > « Confirmer une initiation de paiement« ), ce qui déclenche la prise en compte du paiement par l’établissement bancaire.

Si le PISP fournit l’IBAN du PSU à débiter dans sa requête, le parcours client est simplifié (« parcours PISP fluide ») :

1) Le PSU est redirigé vers un écran de confirmation du virement unitaire ou multipledans lequel seul le compte correspondant à l’IBAN du PSU est proposé au PSU.

3) Le PSU valide l’opération.

4) Le PSU est redirigé vers un écran d’identification et d’authentification forte proposé par son établissement pour valider son paiement.

La cinématique de cette étape dépend de la méthode d’authentification forte mise à disposition du PSU par l’établissement bancaire (SMS OTP, Secur’pass, etc.).

Elle dépend aussi de l’équipement bancaire du PSU sur lequel tourne l’application du PSU (PC ou mobile/tablette).

5) Le PSU est redirigé vers un écran de confirmation de l’opération proposé par son établissement bancaire.

6) Le PSU est redirigé vers l’application du PISP.

7) Vous transmettez la requête de confirmation de l’initiation du paiement via la méthode POST /payment-requests/{paymentRequestResourceId}/confirmation (cf. rubrique « Cas d’usage » > « Confirmer une initiation de paiement« ), ce qui déclenche la prise en compte du paiement par l’établissement bancaire.

Le PISP fournit lors de sa demande d’initiation une ou deux URL call back :

• La première sera appelée par l’établissement bancaire dans le cas où la demande d’initiation est traitée et si le PSU a donné son consentement pour le paiement.

• La seconde URL call back sera utilisée par l’établissement bancaire en cas de refus du consentement. Cette seconde URL est facultative : la première URL de call back sera utilisée si la seconde n’est pas renseignée.

Le PISP peut renseigner un indicateur lui permettant d’indiquer qu’il considère la demande de paiement comme étant un cas d’exemption de SCA. La décision finale d’appliquer ou non une SCA reste à l’ASPSP : à ce jour aucune exemption n’est acceptée parmi les cas de dérogations à l’obligation d’authentification forte du PSU, si les exigences générales en matière d’authentification sont remplies, telles que décrits dans l’article 2 des RTS de la DSP2.

Récupérer le statut d’une initiation du paiement

Vous récupérez le statut d’une initiation de paiement via la méthode GET /payment-requests/{paymentRequestResourceId} (cf. rubrique « Cas d’usage » > « Récupérer le statut d’une initiation de paiement« ).

Cet appel vous permet de récupérer l’ensemble des données de l’initiation de paiement enrichies du resourceId et des statuts de l’initiation et du ou des paiements qu’elle contient.

Les données sont accessibles pendant 35 jours.

Annuler une initiation de Paiement

Pour un virement unitaire ou multipleSCT différé qui n’a pas encore été exécuté ou pour un virement unitaire SCT permanent dont la dernière échéance n’a pas été atteinte, vous annulez une initiation de paiement via la méthode PUT /payment-requests/{paymentRequestResourceId}(cf. rubrique « Cas d’usage » > « Annuler une initiation de paiement« )

La méthode d’authentification supportée par l’établissement bancaire est le mode REDIRECT :

1) Le PSU est redirigé vers un écran d’identification proposé par son établissement bancaire et dans lequel il saisira son identifiant de banque à distance.

2) Le PSU est redirigé vers un écran d’authentification forte proposé par son établissement bancaire pour valider son identité.

3) Le PSU est redirigé vers un écran récapitulatif de l’opération en cours d’annulation proposé par son établissement bancaire.

4) Le PSU valide l’annulation de l’initiation du paiement.

5) Le PSU est redirigé vers un écran de confirmation de l’opération proposé par son établissement bancaire.

6) Le PSU est redirigé vers l’application du TPP PISP.

Le PISP fournit lors de sa demande d’annulation une ou deux URL de call back :

La première sera appelée par l’établissement bancaire dans le cas où la demande d’annulation est traitée et si le PSU a donné son consentement pour cette annulation d’opération.

La seconde URL sera utilisée par l’établissement bancaire en cas de refus du consentement ou de problème. Cette seconde URL est facultative : la première URL call back sera utilisée si la seconde n’est pas renseignée.

Confirmer une initiation de paiement

Vous confirmez une initiation de paiement via la méthode POST /payment-requests/{paymentRequestResourceId}/confirmation, approche REDIRECT renforcé (voir la rubrique « Cas d’usage » > « Confirmer une initiation de paiement« ).

Par contre, le service de confirmation d’une annulation de demande de paiement ne sera pas supporté. L’annulation sera effective dès l’acceptation de la demande.

Récupérer un jeton

Développement pas à pas

1- Le TPP envoie directement une requête vers l’infrastructure informatique d’autorisation de la banque teneur de compte.

Pour l’accès en production (live), le point d’entrée pour récupérer le jeton d’accès dépend de l’établissement teneur de compte avec le format

• htpps://www.<cdetab>.live.api.89c3.com/stet/psd2/oauth/token

ou

• htpps://www.<cdetab>.live.api.<banque>/stet/psd2/oauth/token aligné sur le nom de domaine de l’accès direct de la <banque>

NB : la liste de nos établissements et les valeurs possibles des <cdetab> et <banque> associés sont précisées dans la rubrique « Limitations« .

Afin de pouvoir interroger le bon backend dans le parcours client, il est donc nécessaire que vous prévoyez de demander au préalable au client son établissement teneur de compte.

NB : Le PSU peut domicilier ses comptes dans plusieurs banques du Groupe BPCE. Dans ce cas, il vous faudra un jeton différent pour accéder à chacun des établissements teneurs de comptes (ASPSP).

Le détail des paramètres de la requête se trouvent ci-après : POST /psd2/oauth/token?client_id={clientId}&scope={scope}[&grant-type=client_credentials]

 

Nom		Description	Type
grant_type	[1..1]	Type d’autorisation demandée	Doit être « client_credentials »
client_id	[1..1]	Votre identification en tant que TPP	Si l’enregistrement du TPP a été réalisé au travers du processus de « GoLive » via notre portail BPCE API : doit être égale à la partie « OrganizationIdentifier » du « Distinguished Name » du certificat eiDAS, en accord avec la spécification ETSI =>numéro d’agrément donné par votre autorité compétente (PSDXX-YYYYYYYY-ZZZZZZZZ) OU Si l’enregistrement du TPP a été réalisé via l’API register : doit être égale au client_id retourné dans la réponse au POST /register
scope	[0..1]	Spécifie le service	Doit être « pisp »

2- L’établissement teneur de compte (ASPSP) va effectuer des vérifications liées au profil du TPP (rôle, validité des certificats et de votre rôle, non révocation de votre profil, etc.)

3- Si ces vérifications effectuées sont concluantes, la banque va répondre au TPP via un code HTTP 200 (OK) avec les données suivantes :

 

Nom		Description	Type
access_token	[1..1]	Jeton d’accès fourni au TPP par l’ASPSP.	ex : « nACXdBo0fULg8fffadFDSGJZALKGEAaxfer72HGDHGx6kJHz »
token_type	[1..1]	Type du jeton fourni	Doit être »Bearer »
expires_in	[0..1]	Durée de vie du jeton (en secondes) utilisable plusieurs fois tant qu’il n’est pas expiré	Numérique=> ex : « 3600 »
scope	[1..1]	Spécifie le service	Doit être « pisp »

Le jeton d’accès doit être utilisé dans toutes les requêtes au niveau du header « Authorization » préfixé par le type de jeton « Bearer ».

Si le jeton a expiré, la requête sera rejetée avec un code HTTP 403 et des données indiquant « Token invalide ». Cette requête pourra être renvoyée une fois qu’un nouveau jeton d’accès de type Client Credential a été demandé et obtenu.

Publications réglementaires

Période	Document
Disponibilité des API DSP2 à date	Télécharger le document
Statistiques T4 2023	Télécharger le document
Statistiques T3 2023	Télécharger le document
Statistiques T2 2023	Télécharger le document
Statistiques T1 2023	Télécharger le document
Statistiques T4 2022	Télécharger le document
Statistiques T3 2022	Télécharger le document
Statistiques T2 2022	Télécharger le document
Statistiques T1 2022	Télécharger le document
Statistiques T4 2021	Télécharger le document
Statistiques T3 2021	Télécharger le document
Statistiques T2 2021	Télécharger le document
Statistiques T1 2021	Télécharger le document
Statistiques T4 2020	Télécharger le document
Statistiques T3 2020	Télécharger le document
Statistiques T2 2020	Télécharger le document
Statistiques T1 2020	Télécharger le document

/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId}/confirmation

paymentRequestConfirmation

Résumé

Confirmation of a payment request using an OAUTH2 Authorization code grant (PISP)

Description

### Description
The PISP confirms one of the following requests or modifications:
– 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
The ASPSP answers with a status of the relevant request and the subsequent Credit Transfer. ### Prerequisites
– The TPP was 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 has previously posted a Request which was saved by the ASPSP (cf. § 4.5.3) – The ASPSP has answered with a location link to the saved Payment Request (cf. § 4.5.4) – The TPP has retrieved the saved request in order to get the relevant resource Ids (cf. § 4.6).
– The PSU was authenticated by the ASPSP through an OAUTH2 authorization code grant flow (REDIRECT approach) and the PISP got the relevant token
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its « OAUTH2 Authorization Code » access token ^{Business flow
Once the PSU was authenticated through an OAUTH2 authorization code grant flow (REDIRECT approach), it is the due to the PISP to confirm the Request to the ASPSP in order to complete the process flow.
The ASPSP must wait for confirmation before executing the subsequent Credit Tranfer.
Any further confirmation by the PISP on the same Payment-Request must be ignored.}

Scopes

• cbpii
• pisp

Paramètres

 

Authorization (required)	string header Access token to be passed as a header
paymentRequestResourceId (required)	string path Identification of the Payment Request Resource
confirmationRequest (required)	ConfirmationResource body Parameters needed for confirmation of the Payment Request. Even though there is no parameter, a Json (void) body structure must be provided.
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

Codes retour

 

200	retrieval of the Payment Request enriched with the status report
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.
409	Conflict. The request could not be completed due to a conflict with the current state of the target resource.
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

/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId}

paymentRequest

Résumé

Cancellation of a Payment/Transfer Request (PISP)

Description

Description
The PISP sent a Payment/Transfer Request through a POST command.
The ASPSP registered the Payment/Transfer Request, updated if necessary the relevant identifiers in order to avoid duplicates and returned the location of the updated Request.
The PISP got the Payment/Transfer Request that was updated with the resource identifiers, and eventually the status of the Payment/Transfer Request and the status of the subsequent credit transfer.
The PISP requests for the payment cancellation (global cancellation) or for some payment instructions cancellation (partial cancellation)
No other modification of the Payment/Transfer Request is allowed.
### Prerequisites
– The TPP was 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 previously posted a Payment/Transfer Request which was saved by the ASPSP (cf. § 4.5.3) – The ASPSP answered with a location link to the saved Payment/Transfer Request (cf. § 4.5.4) – The PISP retrieved the saved Payment/Transfer Request (cf. § 4.5.4)
– The TPP and the ASPSP successfully processed a mutual check and authentication
– The TPP presented its « OAUTH2 Client Credential » access token.
– The TPP presented the payment/transfer request.
– The PSU was successfully authenticated. ^{Business flow}
# Payment/Transfer request cancellation circumstances
The cancellation of a Payment/Transfer request might be triggered by the PISP upon request of the PSU.
It can also be triggered by the PISP itself in case of error or fraud detection.
Since the consequence of the cancellation will be a rejection of the Payment/Transfer request globally or limited to some of its instructions, the modification of the payment request will focus on setting the relevant status to the value « CANC ».
This « CANC » status must however be explained through a reason code that can be set with the following values: | Reason | description |
| —— | ———– |
| DS02 | The PSU himsef/herself ordered the cancellation. |
| DUPL | The PISP requested the cancellation for a duplication of a previous Payment/Transfer request |
| FRAD | The PISP requested the cancellation for fraudulent origin of the Payment/Transfer request |
| TECH | The PISP requested the cancellation for a technical issue on its side | #### Payment/Transfer request cancellation level
– Case of a payment with multiple instructions or a standing order, the PISP asks to cancel the whole Payment/Transfer or Standing Order Request including all non-executed payment instructions by setting the [paymentInformationStatus] and the relevant [statusReasonInformation] at payment level.
– Case of a payment with multiple instructions, the PISP asks to cancel one or several payment instructions by setting the [transactionStatus] and the relevant [statusReasonInformation] at each relevant instruction level. The cancellation request might need a PSU authentication before committing, especially when the request is PSU-driven. In other cases, the ASPSP may consider that a PSU authentication is irrelevant.
In order to meet all possibilities, the cancellation request must nevertheless include:
– The specification of the authentication approaches that are supported by the PISP (any combination of « REDIRECT » 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 Transfer 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 « DECOUPLED » approach, a PSU identifier that can be processed by the ASPSP for PSU recognition. – The ASPSP saves the updated Payment/Transfer Request and answers to the PISP. The answer embeds – 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 an authentication. Case of the PSU neither gives nor denies his/her consent, the Cancellation Request shall expire and is then rejected to the PISP. The expiration delay is specified by each ASPSP.
If any modification of the payment request other than cancellation is applied by the PISP, the ASPSP must reject the request with HTTP403 without modifying the payment request resource. There is no need for the PISP to post a confirmation of the cancellation request.

Scopes

• pisp
• cbpii

Paramètres

 

Authorization (required)	string header Access token to be passed as a header
paymentRequestResourceId (required)	string path Identification of the Payment Request Resource
paymentRequest (required)	PaymentRequestResource body Model Example { « resourceId (string) »: « API: Identifier assigned by the ASPSP for further use of the created resource through API calls.\nThe API client cannot set or modify the value of this field.\nSince 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.\nHowever it is the duty of each ASPSP to perform its own risk analysis on this topic.\n », « paymentInformationId (string) »: « ISO20022: Reference assigned by a sending party to unambiguously identify the payment information block within the message.\nAPI: 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.\n », « batchBooking (boolean) »: « 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.\nMeaning When True: Identifies that a batch entry for the sum of the amounts of all transactions in the batch or message is requested.\nMeaning When False: Identifies that a single entry for each of the transactions in the batch or message is requested.\nDefault value: each ASPSP must be able to specify its own default value.\n », « creationDateTime (string) »: « ISO20022: Date and time at which a (group of) payment instruction(s) was created by the instructing party.\n », « numberOfTransactions (integer) »: « ISO20022: Number of individual transactions contained in the message.\nAPI: Each ASPSP will specify a maximum value for this field taking into accounts its specificities about payment request handling\n », « initiatingParty »: { « name (string) »: « ISO20022: Name by which a party is known and which is usually used to identify that party.\nThe [organisationId] property allows the specification of an unique and unambiguous way to identify an organisation.\nThe [privateId] property allows the specification of an unique and unambiguous way to identify a person.\n », « dateAndPlaceOfBirth »: { « birthDate (string) »: « Date on which a person is born. », « cityOfBirth (string) »: « City where a person was born. », « countryOfBirth (string) »: « Country where a person was born. » }, « postalAddress »: { « addressType (string) »: « ISO20022: Identifies the nature of the postal address.\nAPI: Cannot be used for SEPA payments. Proprietary codes can be specified and documented if needed.\n| Code | Name | Description |\n| —- | —- | ———– |\n| BIZZ | Business | Address is the business address |\n| DLVY | Delivery | Address is the address to which delivery is to take place |\n| MLTO | Mail To | Address is the address to which mail is sent |\n| PBOX | PO Box | Address is is a postal office (PO) box |\n| ADDR | Postal | Address is the complete postal address |\n| HOME | Business | Address is the home address |\n », « department (string) »: « ISO20022: Identification of a division of a large organisation or building.\nAPI: Cannot be used for SEPA payments.\n », « subDepartment (string) »: « ISO20022: Identification of a sub-division of a large organisation or building.\nAPI: Cannot be used for SEPA payments.\n », « streetName (string) »: « ISO20022: Name of a street or thoroughfare.\nAPI: Cannot be used for SEPA payments.\n », « buildingNumber (string) »: « ISO20022: Number that identifies the position of a building on a street.\nAPI: Cannot be used for SEPA payments.\n », « buildingName (string) »: « ISO20022: Name of the building or house.\nAPI: Cannot be used for SEPA payments.\n », « postCode (string) »: « ISO20022: Identifier consisting of a group of letters and\/or numbers that is added to a postal address to assist the sorting of mail.\nAPI: Cannot be used for SEPA payments.\n », « townName (string) »: « ISO20022: Name of a built-up area, with defined boundaries, and a local government.\nAPI: Cannot be used for SEPA payments.\n », « countrySubDivision (string) »: « ISO20022: Identifies a subdivision of a country such as state, region, county.\nAPI: Cannot be used for SEPA payments.\n », « country (string) »: « ISO20022: Country in which a person resides (the place of a person’s home). In the case of a company, it is the country from which the affairs of that company are directed.\n », « addressLine (array) »: « Unstructured address. The lines must embed zip code and town name.\nFor SEPA payments, only two address lines are allowed.\n » }, « contactDetails »: { « phoneNumber (string) »: « The collection of information which identifies a specific phone or FAX number as defined by telecom services.\nIt consists of a \ »+\ » followed by the country code (from 1 to 3 characters) then a \ »-\ » and finally, any combination of numbers, \ »(\ », \ »)\ », \ »+\ » and \ »-\ » (up to 30 characters).\n », « faxNumber (string) »: « The collection of information which identifies a specific phone or FAX number as defined by telecom services.\nIt consists of a \ »+\ » followed by the country code (from 1 to 3 characters) then a \ »-\ » and finally, any combination of numbers, \ »(\ », \ »)\ », \ »+\ » and \ »-\ » (up to 30 characters).\n », « emailAddress (string) »: « email address of the contact » }, « organisationId »: { « identification (string) »: « API: Identifier\n », « schemeName (string) »: « Name of the identification scheme.\nPossible values for the scheme name, partially based on ISO20022 external code list, are the following:\n| Code | Name | Description |\n| —- | —- | ———– |\n| BANK | BankPartyIdentification | Unique and unambiguous assignment made by a specific bank or similar financial institution to identify a relationship as defined between the bank and its client. |\n| BBAN | BBANIdentifier | Basic Bank Account Number (BBAN) – identifier used nationally by financial institutions, ie, in individual countries, generally as part of a National Account Numbering Scheme(s), to uniquely identify the account of a customer. |\n| COID | CountryIdentificationCode) : Country authority given organisation identification (e.g., corporate registration number) |\n| SREN | SIREN | The SIREN number is a 9 digit code assigned by INSEE, the French National Institute for Statistics and Economic Studies, to identify an organisation in France. |\n| SRET | SIRET | The SIRET number is a 14 digit code assigned by INSEE, the French National Institute for Statistics and Economic Studies, to identify an organisation unit in France. It consists of the SIREN number, followed by a five digit classification number, to identify the local geographical unit of that entity. |\n| NIDN | NationalIdentityNumber | Number assigned by an authority to identify the national identity number of a person. |\nOther values are also permitted, for instance:\n| Code | Name | Description |\n| —- | —- | ———– |\n| OAUT | OAUTH2 | OAUTH2 access token that is owned by the PISP being also an AISP and that can be used in order to identify the PSU |\n| CPAN | CardPan | Card PAN |\n| MPAN | MaskedPan | Card PAN where some digits were replaced for security reason |\n| TPAN | TokenizedPan | Token which was provided by a Token Service Provider (TSP) in order to obfuscate a real card PAN. The TSP must be identified in the issuer field |\n| TBAN | TokenizedIBAN | Token which was provided by a Token Service Provider (TSP) in order to obfuscate an IBAN. The TSP must be identified in the issuer field |\nEach implementation of the STET PSD2 API must specify in its own documentation which schemes can actually been used\n », « issuer (string) »: « ISO20022: Entity that assigns the identification. this could a country code or any organisation name or identifier that can be recognized by both parties\n » }, « privateId »: { « identification (string) »: « API: Identifier\n », « schemeName (string) »: « Name of the identification scheme.\nPossible values for the scheme name, partially based on ISO20022 external code list, are the following:\n| Code | Name | Description |\n| —- | —- | ———– |\n| BANK | BankPartyIdentification | Unique and unambiguous assignment made by a specific bank or similar financial institution to identify a relationship as defined between the bank and its client. |\n| BBAN | BBANIdentifier | Basic Bank Account Number (BBAN) – identifier used nationally by financial institutions, ie, in individual countries, generally as part of a National Account Numbering Scheme(s), to uniquely identify the account of a customer. |\n| COID | CountryIdentificationCode) : Country authority given organisation identification (e.g., corporate registration number) |\n| SREN | SIREN | The SIREN number is a 9 digit code assigned by INSEE, the French National Institute for Statistics and Economic Studies, to identify an organisation in France. |\n| SRET | SIRET | The SIRET number is a 14 digit code assigned by INSEE, the French National Institute for Statistics and Economic Studies, to identify an organisation unit in France. It consists of the SIREN number, followed by a five digit classification number, to identify the local geographical unit of that entity. |\n| NIDN | NationalIdentityNumber | Number assigned by an authority to identify the national identity number of a person. |\nOther values are also permitted, for instance:\n| Code | Name | Description |\n| —- | —- | ———– |\n| OAUT | OAUTH2 | OAUTH2 access token that is owned by the PISP being also an AISP and that can be used in order to identify the PSU |\n| CPAN | CardPan | Card PAN |\n| MPAN | MaskedPan | Card PAN where some digits were replaced for security reason |\n| TPAN | TokenizedPan | Token which was provided by a Token Service Provider (TSP) in order to obfuscate a real card PAN. The TSP must be identified in the issuer field |\n| TBAN | TokenizedIBAN | Token which was provided by a Token Service Provider (TSP) in order to obfuscate an IBAN. The TSP must be identified in the issuer field |\nEach implementation of the STET PSD2 API must specify in its own documentation which schemes can actually been used\n », « issuer (string) »: « ISO20022: Entity that assigns the identification. this could a country code or any organisation name or identifier that can be recognized by both parties\n » }, « lei (string) »: « Legal Entity Identifier is a code allocated to a party as described in ISO 17442 \ »Financial Services – Legal Entity Identifier (LEI)\ ».\n » }, « acceptDebtorAccountChange (boolean) »: « indicator that the debtor account can be changed in the payment request by the ASPSP if needed\n- true: debtor account can be changed (default value)\n- false: debtor account cannot be changed\n », « acceptChargeHandlingChange (boolean) »: « indicator that the charge handling can be changed in the payment request by the ASPSP if needed\n- true: charge handling can be changed (default value)\n- false: charge handling cannot be changed\n », « acceptInstantPaymentDowngrade (boolean) »: « 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.\nEventually, 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 \u201cINST\u201d value in order to keep the PISP informed.\n- true: payment method can be downgraded\n- false: payment method cannot be downgraded (default value)\n », « paymentTypeInformation »: { « instructionPriority (string) »: « ISO20022: Indicator of the urgency or order of importance that the instructing party would like the instructed party to apply to the processing of the instruction.\nAPI: This field is useless for SCTInst and thus should be ignored.\n », « serviceLevel (string) »: « ISO20022: Agreement under which or rules under which the transaction should be processed. Specifies a pre-agreed service or level of service between the parties, as published in an external service level code list.\nAPI: Only \ »SEPA\ » (SEPA Credit Transfer) value is allowed\n », « localInstrument (string) »: « ISO20022: User community specific instrument.\nUsage: This element is used to specify a local instrument, local clearing option and\/or further qualify the service or service level.\nAPI: \ »INST\ » value is to be used in order to ask for an SEPA instant Payment (SCTInst).\nFor International payments, this field may be valued with one of the ISO20022 external code to specify with payment instrument should be used by the creditor’s bank.\n », « categoryPurpose (string) »: « ISO20022: Specifies the high level purpose of the instruction based on a set of pre-defined categories. This is used by the initiating party to provide information concerning the processing of the payment. It is likely to trigger special processing by any of the agents involved in the payment chain.\nAPI: The following values are allowed:\n| Code | Name | Description |\n| —- | —- | ———- |\n| CASH | CashManagementTransfer | Transaction is a general cash management instruction. |\n| CORT | TradeSettlementPayment | Transaction is related to settlement of a trade, e.g. a foreign exchange deal or a securities transaction. |\n| DVPM | DeliverAgainstPayment | Code used to pre-advise the account servicer of a forthcoming deliver against payment instruction. |\n| INTC | IntraCompanyPayment | Transaction is an intra-company payment, i.e. a payment between two companies belonging to the same group. |\n| SALA | SalaryPayment | Transaction is the payment of salaries. |\n| TREA | TreasuryPayment | Transaction is related to treasury operations. E.g. financial contract settlement. |\n » }, « debtor »: { « name (string) »: « ISO20022: Name by which a party is known and which is usually used to identify that party.\nThe [organisationId] property allows the specification of an unique and unambiguous way to identify an organisation.\nThe [privateId] property allows the specification of an unique and unambiguous way to identify a person.\n », « dateAndPlaceOfBirth »: { « birthDate (string) »: « Date on which a person is born. », « cityOfBirth (string) »: « City where a person was born. », « countryOfBirth (string) »: « Country where a person was born. » }, « postalAddress »: { « addressType (string) »: « ISO20022: Identifies the nature of the postal address.\nAPI: Cannot be used for SEPA payments. Proprietary codes can be specified and documented if needed.\n| Code | Name | Description |\n| —- | —- | ———– |\n| BIZZ | Business | Address is the business address |\n| DLVY | Delivery | Address is the address to which delivery is to take place |\n| MLTO | Mail To | Address is the address to which mail is sent |\n| PBOX | PO Box | Address is is a postal office (PO) box |\n| ADDR | Postal | Address is the complete postal address |\n| HOME | Business | Address is the home address |\n », « department (string) »: « ISO20022: Identification of a division of a large organisation or building.\nAPI: Cannot be used for SEPA payments.\n », « subDepartment (string) »: « ISO20022: Identification of a sub-division of a large organisation or building.\nAPI: Cannot be used for SEPA payments.\n », « streetName (string) »: « ISO20022: Name of a street or thoroughfare.\nAPI: Cannot be used for SEPA payments.\n », « buildingNumber (string) »: « ISO20022: Number that identifies the position of a building on a street.\nAPI: Cannot be used for SEPA payments.\n », « buildingName (string) »: « ISO20022: Name of the building or house.\nAPI: Cannot be used for SEPA payments.\n », « postCode (string) »: « ISO20022: Identifier consisting of a group of letters and\/or numbers that is added to a postal address to assist the sorting of mail.\nAPI: Cannot be used for SEPA payments.\n », « townName (string) »: « ISO20022: Name of a built-up area, with defined boundaries, and a local government.\nAPI: Cannot be used for SEPA payments.\n », « countrySubDivision (string) »: « ISO20022: Identifies a subdivision of a country such as state, region, county.\nAPI: Cannot be used for SEPA payments.\n », « country (string) »: « ISO20022: Country in which a person resides (the place of a person’s home). In the case of a company, it is the country from which the affairs of that company are directed.\n », « addressLine (array) »: « Unstructured address. The lines must embed zip code and town name.\nFor SEPA payments, only two address lines are allowed.\n » }, « contactDetails »: { « phoneNumber (string) »: « The collection of information which identifies a specific phone or FAX number as defined by telecom services.\nIt consists of a \ »+\ » followed by the country code (from 1 to 3 characters) then a \ »-\ » and finally, any combination of numbers, \ »(\ », \ »)\ », \ »+\ » and \ »-\ » (up to 30 characters).\n », « faxNumber (string) »: « The collection of information which identifies a specific phone or FAX number as defined by telecom services.\nIt consists of a \ »+\ » followed by the country code (from 1 to 3 characters) then a \ »-\ » and finally, any combination of numbers, \ »(\ », \ »)\ », \ »+\ » and \ »-\ » (up to 30 characters).\n », « emailAddress (string) »: « email address of the contact » }, « organisationId »: { « identification (string) »: « API: Identifier\n », « schemeName (string) »: « Name of the identification scheme.\nPossible values for the scheme name, partially based on ISO20022 external code list, are the following:\n| Code | Name | Description |\n| —- | —- | ———– |\n| BANK | BankPartyIdentification | Unique and unambiguous assignment made by a specific bank or similar financial institution to identify a relationship as defined between the bank and its client. |\n| BBAN | BBANIdentifier | Basic Bank Account Number (BBAN) – identifier used nationally by financial institutions, ie, in individual countries, generally as part of a National Account Numbering Scheme(s), to uniquely identify the account of a customer. |\n| COID | CountryIdentificationCode) : Country authority given organisation identification (e.g., corporate registration number) |\n| SREN | SIREN | The SIREN number is a 9 digit code assigned by INSEE, the French National Institute for Statistics and Economic Studies, to identify an organisation in France. |\n| SRET | SIRET | The SIRET number is a 14 digit code assigned by INSEE, the French National Institute for Statistics and Economic Studies, to identify an organisation unit in France. It consists of the SIREN number, followed by a five digit classification number, to identify the local geographical unit of that entity. |\n| NIDN | NationalIdentityNumber | Number assigned by an authority to identify the national identity number of a person. |\nOther values are also permitted, for instance:\n| Code | Name | Description |\n| —- | —- | ———– |\n| OAUT | OAUTH2 | OAUTH2 access token that is owned by the PISP being also an AISP and that can be used in order to identify the PSU |\n| CPAN | CardPan | Card PAN |\n| MPAN | MaskedPan | Card PAN where some digits were replaced for security reason |\n| TPAN | TokenizedPan | Token which was provided by a Token Service Provider (TSP) in order to obfuscate a real card PAN. The TSP must be identified in the issuer field |\n| TBAN | TokenizedIBAN | Token which was provided by a Token Service Provider (TSP) in order to obfuscate an IBAN. The TSP must be identified in the issuer field |\nEach implementation of the STET PSD2 API must specify in its own documentation which schemes can actually been used\n », « issuer (string) »: « ISO20022: Entity that assigns the identification. this could a country code or any organisation name or identifier that can be recognized by both parties\n » }, « privateId »: { « identification (string) »: « API: Identifier\n », « schemeName (string) »: « Name of the identification scheme.\nPossible values for the scheme name, partially based on ISO20022 external code list, are the following:\n| Code | Name | Description |\n| —- | —- | ———– |\n| BANK | BankPartyIdentification | Unique and unambiguous assignment made by a specific bank or similar financial institution to identify a relationship as defined between the bank and its client. |\n| BBAN | BBANIdentifier | Basic Bank Account Number (BBAN) – identifier used nationally by financial institutions, ie, in individual countries, generally as part of a National Account Numbering Scheme(s), to uniquely identify the account of a customer. |\n| COID | CountryIdentificationCode) : Country authority given organisation identification (e.g., corporate registration number) |\n| SREN | SIREN | The SIREN number is a 9 digit code assigned by INSEE, the French National Institute for Statistics and Economic Studies, to identify an organisation in France. |\n| SRET | SIRET | The SIRET number is a 14 digit code assigned by INSEE, the French National Institute for Statistics and Economic Studies, to identify an organisation unit in France. It consists of the SIREN number, followed by a five digit classification number, to identify the local geographical unit of that entity. |\n| NIDN | NationalIdentityNumber | Number assigned by an authority to identify the national identity number of a person. |\nOther values are also permitted, for instance:\n| Code | Name | Description |\n| —- | —- | ———– |\n| OAUT | OAUTH2 | OAUTH2 access token that is owned by the PISP being also an AISP and that can be used in order to identify the PSU |\n| CPAN | CardPan | Card PAN |\n| MPAN | MaskedPan | Card PAN where some digits were replaced for security reason |\n| TPAN | TokenizedPan | Token which was provided by a Token Service Provider (TSP) in order to obfuscate a real card PAN. The TSP must be identified in the issuer field |\n| TBAN | TokenizedIBAN | Token which was provided by a Token Service Provider (TSP) in order to obfuscate an IBAN. The TSP must be identified in the issuer field |\nEach implementation of the STET PSD2 API must specify in its own documentation which schemes can actually been used\n », « issuer (string) »: « ISO20022: Entity that assigns the identification. this could a country code or any organisation name or identifier that can be recognized by both parties\n » }, « lei (string) »: « Legal Entity Identifier is a code allocated to a party as described in ISO 17442 \ »Financial Services – Legal Entity Identifier (LEI)\ ».\n » }, « debtorAccount »: { « workspace (string) »: « Workspace to which the account is linked.\nThis workspace might be specified by the AISP when forwarding the consent on accounts.\nIf not provided, the default workspace is computed from the authentication that was used for getting the OAuth2 Access Token.\n », « iban (string) »: « ISO20022: International Bank Account Number (IBAN) – identification used internationally by financial institutions to uniquely identify the account of a customer.\n\nFurther specifications of the format and content of the IBAN can be found in the standard ISO 13616 \ »Banking and related financial services – International Bank Account Number (IBAN)\ » version 1997-10-01, or later revisions.\n », « other »: { « identification (string) »: « API: Identifier\n », « schemeName (string) »: « Name of the identification scheme.\nPossible values for the scheme name, partially based on ISO20022 external code list, are the following:\n| Code | Name | Description |\n| —- | —- | ———– |\n| BANK | BankPartyIdentification | Unique and unambiguous assignment made by a specific bank or similar financial institution to identify a relationship as defined between the bank and its client. |\n| BBAN | BBANIdentifier | Basic Bank Account Number (BBAN) – identifier used nationally by financial institutions, ie, in individual countries, generally as part of a National Account Numbering Scheme(s), to uniquely identify the account of a customer. |\n| COID | CountryIdentificationCode) : Country authority given organisation identification (e.g., corporate registration number) |\n| SREN | SIREN | The SIREN number is a 9 digit code assigned by INSEE, the French National Institute for Statistics and Economic Studies, to identify an organisation in France. |\n| SRET | SIRET | The SIRET number is a 14 digit code assigned by INSEE, the French National Institute for Statistics and Economic Studies, to identify an organisation unit in France. It consists of the SIREN number, followed by a five digit classification number, to identify the local geographical unit of that entity. |\n| NIDN | NationalIdentityNumber | Number assigned by an authority to identify the national identity number of a person. |\nOther values are also permitted, for instance:\n| Code | Name | Description |\n| —- | —- | ———– |\n| OAUT | OAUTH2 | OAUTH2 access token that is owned by the PISP being also an AISP and that can be used in order to identify the PSU |\n| CPAN | CardPan | Card PAN |\n| MPAN | MaskedPan | Card PAN where some digits were replaced for security reason |\n| TPAN | TokenizedPan | Token which was provided by a Token Service Provider (TSP) in order to obfuscate a real card PAN. The TSP must be identified in the issuer field |\n| TBAN | TokenizedIBAN | Token which was provided by a Token Service Provider (TSP) in order to obfuscate an IBAN. The TSP must be identified in the issuer field |\nEach implementation of the STET PSD2 API must specify in its own documentation which schemes can actually been used\n », « issuer (string) »: « ISO20022: Entity that assigns the identification. this could a country code or any organisation name or identifier that can be recognized by both parties\n » }, « currency (string) »: « Specifies the currency of the amount or of the account.\nA code allocated to a currency by a Maintenance Agency under an international identification scheme, as described in the latest edition of the international standard ISO 4217 \ »Codes for the representation of currencies and funds\ ».\n » }, « debtorAgent »: { « bicFi (string) »: « ISO20022: Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362 \ »Banking – Banking telecommunication messages – Business identification code (BIC)\ ».\n », « clearingSystemMemberId »: { « clearingSystemId (string) »: « ISO20022: Specification of a pre-agreed offering between clearing agents or the channel through which the payment instruction is processed.\n », « memberId (string) »: « ISO20022: Identification of a member of a clearing system.\n » }, « lei (string) »: « Legal Entity Identifier is a code allocated to a party as described in ISO 17442 \ »Financial Services – Legal Entity Identifier (LEI)\ ».\n », « name (string) »: « Name of the financial institution », « postalAddress »: { « addressType (string) »: « ISO20022: Identifies the nature of the postal address.\nAPI: Cannot be used for SEPA payments. Proprietary codes can be specified and documented if needed.\n| Code | Name | Description |\n| —- | —- | ———– |\n| BIZZ | Business | Address is the business address |\n| DLVY | Delivery | Address is the address to which delivery is to take place |\n| MLTO | Mail To | Address is the address to which mail is sent |\n| PBOX | PO Box | Address is is a postal office (PO) box |\n| ADDR | Postal | Address is the complete postal address |\n| HOME | Business | Address is the home address |\n », « department (string) »: « ISO20022: Identification of a division of a large organisation or building.\nAPI: Cannot be used for SEPA payments.\n », « subDepartment (string) »: « ISO20022: Identification of a sub-division of a large organisation or building.\nAPI: Cannot be used for SEPA payments.\n », « streetName (string) »: « ISO20022: Name of a street or thoroughfare.\nAPI: Cannot be used for SEPA payments.\n », « buildingNumber (string) »: « ISO20022: Number that identifies the position of a building on a street.\nAPI: Cannot be used for SEPA payments.\n », « buildingName (string) »: « ISO20022: Name of the building or house.\nAPI: Cannot be used for SEPA payments.\n », « postCode (string) »: « ISO20022: Identifier consisting of a group of letters and\/or numbers that is added to a postal address to assist the sorting of mail.\nAPI: Cannot be used for SEPA payments.\n », « townName (string) »: « ISO20022: Name of a built-up area, with defined boundaries, and a local government.\nAPI: Cannot be used for SEPA payments.\n », « countrySubDivision (string) »: « ISO20022: Identifies a subdivision of a country such as state, region, county.\nAPI: Cannot be used for SEPA payments.\n », « country (string) »: « ISO20022: Country in which a person resides (the place of a person’s home). In the case of a company, it is the country from which the affairs of that company are directed.\n », « addressLine (array) »: « Unstructured address. The lines must embed zip code and town name.\nFor SEPA payments, only two address lines are allowed.\n » } }, « chargeBearer (string) »: « ISO20022: Specifies which party\/parties will bear the charges associated with the processing of the payment transaction.\nThe following values are allowed:\n| Code | Name | Description |\n| —- | —- | ———- |\n| DEBT | BorneByDebtor | All transaction charges are to be borne by the debtor. |\n| CRED | BorneByCreditor | All transaction charges are to be borne by the creditor. |\n| SHAR | Shared | In a credit transfer context, means that transaction charges on the sender side are to be borne by the debtor, transaction charges on the receiver side are to be borne by the creditor. In a direct debit context, means that transaction charges on the sender side are to be borne by the creditor, transaction charges on the receiver side are to be borne by the debtor. |\n| SLEV | FollowingServiceLevel | Charges are to be applied following the rules agreed in the service level and\/or scheme. |\n », « paymentInformationStatus (string) »: « ISO20022: Specifies the status of the payment information.\nAPI: Mandatory. The following values are allowed to provide the status of the Payment Request\n| Code | Name | Description |\n| —- | —- | ———- |\n| ACCO | AcceptedCustomerCOnfirmed | The customer, during his\/her authentication, has confirmed the payment request. |\n| ACCP | AcceptedCustomerProfile | Preceding check of technical validation was successful. Customer profile check was also successful. |\n| 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. |\n| 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. |\n| ACTC | AcceptedTechnicalValidation | Authentication and syntactical and semantical validation are successful. |\n| ACWC | AcceptedWithChange | Instruction is accepted but a change will be made, such as date or remittance not sent. |\n| ACWP | AcceptedWithoutPosting | Payment instruction included in the credit transfer is accepted without being posted to the creditor customer\u2019s account. |\n| CANC | Cancelled | Payment initiation was successfully cancelled after having received a request for cancellation. |\n| PART | PartiallyAccepted | A number of transactions were accepted, whereas another number of transactions have not yet achieved ‘accepted’ status. |\n| PATC | PartiallyAcceptedTechnicalCorrect | Payment initiation needs multiple authentications, where some but not yet all were performed. Syntactical and semantical validations are successful. |\n| RCVD | Received | Payment initiation was received by the receiving agent. |\n| PDNG | Pending | Payment request or individual transaction included in the Payment Request is pending. Further checks and status update will be performed. |\n| RJCT | Rejected | Payment request was rejected. |\n\n », « statusReasonInformation (string) »: « ISO20022: Provides detailed information on the status reason.\n\nAPI: Can only be used in case the status is equal to \ »RJCT\ » or \ »CANC\ ». Only the following values are allowed:\n| Code | Name | Description |\n| —- | —- | ———- |\n| AC01 | IncorectAccountNumber | the account number is either invalid or does not exist |\n| AC04 | ClosedAccountNumber | the account is closed and cannot be used |\n| AC06 | BlockedAccount | the account is blocked and cannot be used |\n| AG01 | TransactionForbidden | Transaction forbidden on this type of account |\n| AG03 | TransactionNotSupported | Transaction type not supported\/authorized on this account |\n| AM18 | InvalidNumberOfTransactions | the number of transactions exceeds the ASPSP acceptance limit |\n| CH03 | RequestedExecutionDateOrRequestedCollectionDateTooFarInFuture | The requested execution date is too far in the future |\n| CH04 | RequestedExecutionDateOrRequestedCollectionDateTooFarInPast | Value in Requested Execution Date or Requested Collection Date is too far in the past |\n| CNOR | CreditorBankIsNotRegistered | Creditor bank is not registered under this BIC in the CSM |\n| CUST | RequestedByCustomer | The reject is due to the debtor: refusal or lack of liquidity |\n| DS02 | OrderCancelled | An authorized user has cancelled the order |\n| DUPL | DuplicatePayment | Payment is a duplicate of another payment. Can only be set by a PISP for a payment request cancellation. |\n| FF01 | InvalidFileFormat | The reject is due to the original Payment Request which is invalid (syntax, structure or values) |\n| FRAD | FraudulentOriginated | the Payment Request is considered as fraudulent |\n| MS03 | NotSpecifiedReasonAgentGenerated | No reason specified by the ASPSP |\n| NOAS | NoAnswerFromCustomer | The PSU has neither accepted nor rejected the Payment Request and a time-out has occurred |\n| RR01 | MissingDebtorAccountOrIdentification | The Debtor account and\/or Identification are missing or inconsistent |\n| RR03 | MissingCreditorNameOrAddress | Specification of the creditor\u2019s name and\/or address needed for regulatory requirements is insufficient or missing. |\n| RR04 | RegulatoryReason | Reject from regulatory reason |\n| RR12 | InvalidPartyID | Invalid or missing identification required within a particular country or payment type. |\n| TECH | TechnicalProblem | Technical problems resulting in an erroneous transaction. Can only be set by a PISP for a payment request cancellation. |\n », « fundsAvailability (boolean) »: « Indicator that the payment can be covered or not by the funds available on the relevant account\n- true: payment is covered\n- false: payment is not covered\nThis indicator must be provided by the ASPSP when the Booking Information is present and set to \ »False\ ».\nThis indicator will not be provided if the Booking Information is absent or set to \ »True\ ».\n », « booking (boolean) »: « Indicator that the payment can be immediately booked or not\n- true: payment is booked\n- false: payment is not booked\nBooking 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.\nHowever, usual fraud detection mechanisms might still be triggered and result as a rejection of the payment.\nThis indicator must be provided when the relevant Credit Transfer will be executed as soon as possible but not as an instant payment.\nThis indicator is irrelevant and will not be provided for delayed payments.\nThis 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.\n\nCase the Information System cannot handle this immediate booking, the ASPSP will have to provide the funds availability information.\n », « creditTransferTransaction (array) »: « ISO20022: Payment processes required to transfer cash from the debtor to the creditor.\nAPI: Each ASPSP will specify a maxItems value for this field taking into accounts its specificities about payment request handling\n », « supplementaryData »: { « acceptedAuthenticationApproach (array) »: « List of authentication approaches », « appliedAuthenticationApproach (string) »: « Authentication approaches that can be applied.\nREDIRECT: the PSU is redirected by the TPP to the ASPSP which processes identification and authentication\nDECOUPLED: the TPP identifies the PSU and forwards the identification to the ASPSP which processes the authentication through a decoupled device\nNONE: there is no need for the PSU to authenticate\n », « appliedAuthentication (string) »: « Can only be set by the ASPSP.\nThis field allows the ASPSP to inform the PISP about the way authentication was processed during the payment request confirmation.\n », « scaHint (string) »: « can only be set by the PISP\nHint given by the merchant and\/or the PISP about an SCA exemption context\n », « successfulReportUrl (string) »: « URL to be used by the ASPSP in order to notify the PISP of the finalisation of the authentication and consent process in REDIRECT and DECOUPLED approach\n », « unsuccessfulReportUrl (string) »: « URL to be used by the ASPSP in order to notify the PISP of the failure of the authentication and consent process in REDIRECT and DECOUPLED approach\nIf this URL is not provided by the PISP, the ASPSP will use the \ »successfulReportUrl\ » even in case of failure of the Payment Request processing\n », « nextStatusRequestHint (string) »: « Date and time at which the PISP is suggested to ask again for the status of the payment request.\n » } } « {\n \ »paymentInformationId\ » : \ »MyPmtInfId\ »,\n \ »creationDateTime\ » : \ »2020-02-19T13:56:54.877+01:00\ »,\n \ »numberOfTransactions\ » : 2,\n \ »initiatingParty\ » : {\n \ »name\ » : \ »MyPreferredPisp\ »,\n \ »postalAddress\ » : {\n \ »country\ » : \ »FR\ »,\n \ »addressLine\ » : [ \ »18 rue de la DSP2\ », \ »75008 PARIS\ » ]\n },\n \ »organisationId\ » : {\n \ »identification\ » : \ »12FR5\ »,\n \ »schemeName\ » : \ »COID\ »,\n \ »issuer\ » : \ »ACPR\ »\n }\n },\n \ »paymentTypeInformation\ » : {\n \ »serviceLevel\ » : \ »SEPA\ »,\n \ »localInstrument\ » : \ »INST\ »,\n \ »categoryPurpose\ » : \ »CASH\ »\n },\n \ »debtor\ » : {\n \ »name\ » : \ »MyCustomer\ »,\n \ »postalAddress\ » : {\n \ »country\ » : \ »FR\ »,\n \ »addressLine\ » : [ \ »18 rue de la DSP2\ », \ »75008 PARIS\ » ]\n },\n \ »privateId\ » : {\n \ »identification\ » : \ »FD37G\ »,\n \ »schemeName\ » : \ »BANK\ »,\n \ »issuer\ » : \ »BICXYYTTZZZ\ »\n }\n },\n \ »chargeBearer\ » : \ »SLEV\ »,\n \ »creditTransferTransaction\ » : [ {\n \ »paymentId\ » : {\n \ »instructionId\ » : \ »MyInstrId3\ »,\n \ »endToEndId\ » : \ »MyEndToEndId3\ »\n },\n \ »requestedExecutionDate\ » : \ »2020-02-19T13:56:54.878+01:00\ »,\n \ »instructedAmount\ » : {\n \ »amount\ » : 124.35,\n \ »currency\ » : \ »EUR\ »\n },\n \ »beneficiary\ » : {\n \ »creditor\ » : {\n \ »name\ » : \ »June Doe\ »,\n \ »postalAddress\ » : {\n \ »country\ » : \ »FR\ »,\n \ »addressLine\ » : [ \ »18 rue de la DSP2\ », \ »75008 PARIS\ » ]\n },\n \ »organisationId\ » : {\n \ »identification\ » : \ »12FR5\ »,\n \ »schemeName\ » : \ »COID\ »,\n \ »issuer\ » : \ »ACPR\ »\n },\n \ »privateId\ » : {\n \ »identification\ » : \ »852126789\ »,\n \ »schemeName\ » : \ »SIREN\ »,\n \ »issuer\ » : \ »FR\ »\n }\n },\n \ »creditorAccount\ » : {\n \ »iban\ » : \ »YY49QEZO90424459988701367845944910\ »,\n \ »currency\ » : \ »EUR\ »\n }\n },\n \ »ultimateCreditor\ » : {\n \ »name\ » : \ »myPreferredUltimateMerchant\ »,\n \ »postalAddress\ » : {\n \ »country\ » : \ »FR\ »,\n \ »addressLine\ » : [ \ »18 rue de la DSP2\ », \ »75008 PARIS\ » ]\n },\n \ »organisationId\ » : {\n \ »identification\ » : \ »85212678900025\ »,\n \ »schemeName\ » : \ »SIRET\ »,\n \ »issuer\ » : \ »FR\ »\n }\n },\n \ »purpose\ » : \ »CASH\ »,\n \ »remittanceInformation\ » : {\n \ »unstructured\ » : [ \ »MyRemittanceInformation\ » ]\n }\n }, {\n \ »paymentId\ » : {\n \ »instructionId\ » : \ »MyInstrId4\ »,\n \ »endToEndId\ » : \ »MyEndToEndId4\ »\n },\n \ »requestedExecutionDate\ » : \ »2020-02-19T13:56:54.878+01:00\ »,\n \ »instructedAmount\ » : {\n \ »amount\ » : 124.35,\n \ »currency\ » : \ »EUR\ »\n },\n \ »beneficiary\ » : {\n \ »creditor\ » : {\n \ »name\ » : \ »John Doe\ »,\n \ »postalAddress\ » : {\n \ »country\ » : \ »FR\ »,\n \ »addressLine\ » : [ \ »18 rue de la DSP2\ », \ »75008 PARIS\ » ]\n },\n \ »organisationId\ » : {\n \ »identification\ » : \ »12FR5\ »,\n \ »schemeName\ » : \ »COID\ »,\n \ »issuer\ » : \ »ACPR\ »\n },\n \ »privateId\ » : {\n \ »identification\ » : \ »852126789\ »,\n \ »schemeName\ » : \ »SIREN\ »,\n \ »issuer\ » : \ »FR\ »\n }\n },\n \ »creditorAccount\ » : {\n \ »iban\ » : \ »YY27KYHO61109079868328944728829436\ »,\n \ »currency\ » : \ »EUR\ »\n }\n },\n \ »ultimateCreditor\ » : {\n \ »name\ » : \ »myPreferredUltimateMerchant\ »,\n \ »postalAddress\ » : {\n \ »country\ » : \ »FR\ »,\n \ »addressLine\ » : [ \ »18 rue de la DSP2\ », \ »75008 PARIS\ » ]\n },\n \ »organisationId\ » : {\n \ »identification\ » : \ »85212678900025\ »,\n \ »schemeName\ » : \ »SIRET\ »,\n \ »issuer\ » : \ »FR\ »\n }\n },\n \ »purpose\ » : \ »CASH\ »,\n \ »remittanceInformation\ » : {\n \ »unstructured\ » : [ \ »MyRemittanceInformation\ » ]\n }\n } ],\n \ »supplementaryData\ » : {\n \ »acceptedAuthenticationApproach\ » : [ \ »REDIRECT\ », \ »DECOUPLED\ » ],\n \ »successfulReportUrl\ » : \ »http:\/\/myPisp\/PaymentSuccess\ »,\n \ »unsuccessfulReportUrl\ » : \ »http:\/\/myPisp\/PaymentFailure\ »\n }\n} » Cliquez pour définir comme valeur de paramètre 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

Codes retour

 

200	The cancellation request was saved. The ASPSP may have to authenticate the PSU before committing the update.
400	Invalid status value
401	Unauthorized, authentication failure.
403	Forbidden, authentication successful but access to resource is not allowed.
404	Not found, no request available.
405	Method Not Allowed.
406	Not Acceptable.
408	Request Timeout.
409	Conflict. The request could not be completed due to a conflict with the current state of the target resource.
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

/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId}/transactions

paymentRequestTransactions

Résumé

Retrieval of the Credit Transfert Transactions that were processed for a given payment request (PISP)

Description

^{Description
The PISP gets the execution history of a payment request.
This entry-point is an alternative to the retrieval of the history through the retrieval of the payment request.
So, each ASPSP may choose or not to implement this entry-point.} Prerequisites
– The TPP was registered by the Registration Authority for the PISP role
– The TPP has previously posted a Standing Order Request which was saved by the ASPSP (cf. § 4.5.3) – The ASPSP has answered with a location link to the saved Payment Request (cf. § 4.5.4) – The TPP has retrieved the saved request in order to get the relevant resource Ids (cf. § 4.6).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP was provided with an OAUTH2 « Client Credential » access token by the ASPSP (cf. § 3.4.2).
– The TPP presented its « OAUTH2 Client Credential » access token. ^{Business flow
The PISP post the history request.
The ASPSP answers with the list of relevant transactions.}

Scopes

• cbpii
• pisp

Paramètres

 

Authorization (required)	string header Access token to be passed as a header
paymentRequestResourceId (required)	string path Identification of the Payment Request Resource
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

Codes retour

 

200	retrieval of the Payment Request enriched with the status report
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.
409	Conflict. The request could not be completed due to a conflict with the current state of the target resource.
429	Too many requests.
500	Internal server error.
503	Service unavailable.

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId}

paymentRequests

Résumé

Retrieval of a payment request (PISP)

Description

Description
The following use cases can be applied:
– retrieval of a payment request on behalf of a merchant
– retrieval of a transfer request on behalf of the account’s owner
– retrieval of a standing-order request on behalf of the account’s owner The PISP has previously sent a Request through a POST command.
– The ASPSP has registered the Request, updated if necessary the relevant identifiers in order to avoid duplicates and returned the location of the updated Request.
– The PISP gets the Request that was updated with the resource identifiers, and eventually the status of the Payment/Transfer Request and the status of the subsequent credit transfer. ### Prerequisites
– The TPP was 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 has previously posted a Request which was saved by the ASPSP (cf. § 4.5.3) – The ASPSP has answered with a location link to the saved Payment/Transfer Request (cf. § 4.5.4)
– 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
The PISP asks to retrieve the Payment/Transfer Request that was saved by the ASPSP. The PISP uses the location link provided by the ASPSP in response of the posting of this request.
The ASPSP returns the previously posted Payment/Transfer Request which is enriched with:
– The resource identifiers given by the ASPSP
– The status information of the Payment Request and of the subsequent credit transfer
The status information must be available during at least 30 calendar days after the posting of the Payment Request. However, the ASPSP may increase this availability duration, based on its own rules.

Scopes

• cbpii
• pisp

Paramètres

 

Authorization (required)	string header Access token to be passed as a header
paymentRequestResourceId (required)	string path Identification of the Payment Request Resource
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

Codes retour

 

200	Retrieval of the previously posted Payment Request
400	Invalid status value
401	Unauthorized, authentication failure.
403	Forbidden, authentication successful but access to resource is not allowed.
404	Not found, no request available.
405	Method Not Allowed.
406	Not Acceptable.
408	Request Timeout.
429	Too many requests.
500	Internal server error.
503	Service unavailable.

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

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

paymentRequests

Résumé

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
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 (at transaction level) | Optional. if set by the PISP, it indicates the date on debit on the ordering party account. If not set by the PISP, this requests the ASPSP to execute the payment instruction as soon as possible. |||
| 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 (at 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 (at transaction level) | Mandatory | Mandatory. Account currency may be specified ||
| CreditorAgent (at transaction level) | Optional |||
| ClearingSystemId et ClearingSystemMemberId (at transaction level) | Not used || Optional |
| IntermediaryAgent et IntermediaryAgentAccount (at transaction level) | Not used | Optional || #### Prerequisites for all use cases
– The TPP was 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 ^{# 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 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. ##### 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

Scopes

• cbpii
• 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.
PSU-Workspace	string header Workspace to be used for processing the PSU authentication when confirming a PISP request.

Codes retour

 

201	The request was 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

Initier un paiement

Envoyer une demande d’initiation de paiement pour un virement unitaire ou un virement multiple en € !

Contexte

Cet appel permet d’envoyer à la banque (ASPSP) d’un client une demande d’initiation de paiement venant débiter son compte. S’il s’agit d’une initiation de paiement initiée par un e-commerçant (pas par le client final), le paiement va créditer celui de l’usager du service de paiement (PSU) pour lequel le Prestataire de service de paiement (PISP) a été mandaté, à savoir le e-commerçant.

Les initiations de paiement d’un virement unitaire ou d’un virement multiple en euros est acceptée dans nos traitements.

A la soumission de la requête, et si toutes les données sont correctement formatées, une réponse (HTPP 201) vous sera retournée.

Cette réponse contiendra le resourceId de l’initiation de paiement, ainsi que le mode d’authentification SCA Redirect (seul mode disponible), l’URL de consentement en fonction de la banque du payeur (urlconsent_approval_URL) et le non rejeu.

Prérequis

Pour procéder à cette requête il est nécessaire de remplir les prérequis d’éligibilité pour le rôle TPP « PISP » (voir la rubrique « Eligibilité« ), et d’avoir récupéré le jeton d’accès OAUTH2 (voir la rubrique « Vue d’ensemble » > « Récupérer un jeton« ).

Requête POST

Le point d’entrée dépendra du code établissement.

Vous devez insérer la même valeur des paramètres <cdetab> et <banque> que celle utilisée pour le jeton d’accès.

Pour rappel, la liste de nos établissements et les valeurs possibles des <cdetab> et <banque> sont précisées dans la rubrique « Limitations« .

Voici un extrait de cette liste :

 

CODE ÉTABLISSEMENT <CDETAB>	NOM DE L’ÉTABLISSEMENT	NOM ABRÉGÉ	<BANQUE>
13807	B.P Grand Ouest	BPGO	banquepopulaire
10548	Banque de Savoie	BQSAV	banque-de-savoie
40978	Banque Palatine	BPAL	palatine

Comme en mode test, le bon référentiel client est adressable via un « endpoint » au format www.<cdetab>.live.api.89c3.com ou www.<cdetab>.live.api.<banque>.fr

Pour exemple, nous avons donc comme URL de production :

• POST https://www.13807.live.api.89c3.com/stet/psd2/v1.6.2/payment-requests ou https://www.13807.live.api.banquepopulaire.fr/stet/psd2/v1.6.2/payment-requests pour initier un paiement pour un client de la BPGO en production

Paramètres obligatoires ou facultatifs du body requis pour l’appel de ce service

La structure du body et les champs obligatoires sont décrits dans la norme STET.

Les informations suivantes doivent être valorisées dans la requête comme suit :

• La donnée serviceLevel doit être renseigné à SEPA

• La donnée currency doit être renseignée à EUR => les virements internationaux en devise ne sont pas disponibles

• La donnée requestedExecutionDate doit être égale ou supérieure à la date du jour

• La donnée remittanceInformation doit intégrer la balise « unstructured » soit par exemple « remittanceInformation » : { « unstructured » : [ « test  » ] }.

• La donnée requestedExecutionDate peut être un week-end ou un jour target 2 pour les SCT. Pour les SCT immédiats uniquement si requestedExecutionDate est le jour même de la demande ; dans ce cas, le paiement sera transformé en un SCT différé programmé pour le jour ouvré suivant. Pour les virements SCT permanents, la première échéance ne peut être positionnée :
  • 30 jours et plus après la date du jour ;
  • Le jour même.

• La donnée executionRule est facultative et ignorée si présente pour les SCT immédiats et différés. Pour les virements SCT permanents, si elle est alimentée, elle ne peut être valorisée qu’avec la valeur « FWNG » (report au jour suivant). L’ASPSP ne modifie pas la date d’exécution de sa propre initiative ; celle positionnée par le TPP doit être une date acceptable pour la banque (cf. remarques sur donnée requestedExecutionDate).

• La donnée frequency ne doit être alimentée que pour les virements SCT permanents, elle est obligatoire dans ce cas. Elle n’accepte que les valeurs MNTH (Monthly), QUTR (Quaterly) et YEAR (Annual). La donnée endDate (date de dernière échéance) ne doit être alimentée que pour les virements SCT permanents :
  • Si elle est renseignée, elle doit correspondre à une échéance valide et dans le futur :
    • requestedExecutionDate + n mois si frequency = MNTH;
    • requestedExecutionDate + n trimestres si frequency = QUTR;
    • requestedExecutionDate + n années si frequency = YEAR;
  • Si non renseignée, elle doit être calculée :
    •  requestedExecutionDate avec l’année qui vaut 2099

• La donnée localInstrument est à alimenter avec la valeur « INST » pour déclencher un SEPA Instant Payment (SCT Inst).
  • Ce type de virement occasionne des frais facturés au client en fonction des conditions tarifaires en vigueur applicables pour son segment de clientèle (IP PART ou IP B2B) ;
  • La banque du bénéficiaire doit être atteignable en IP ;
  • Pour les clients professionnels et entreprises, les comptes émetteurs et les pays des bénéficiaires éligibles pour ce type de virement sont définis sur le contrat de flux IP B2B.

• La donnée localInstrument ne doit pas être présente pour les SCT immédiats, différés ou permanents.

• Seuls les IBAN complets sont supportés pour les données « Iban« , « debtorAccount » et « creditorAccount »
  • La présence de lettre minuscules dans les IBAN (et spécialement pour la donnée creditorAccount) est acceptée pour la prise en compte d’une demande d’initiation de paiement. Cependant, pour ce qui concerne les Banques Populaires, la Banque de Savoie et la Banque Palatine, bien que le parcours client va se dérouler normalement jusqu’à la validation du virement par le PSU avec authentification forte, le virement sera in fine refusé par le SI des Banques Populaires qui ne supporte pas les IBAN possédant des lettres en minuscules. Un message d’erreur sera affiché au PSU sur le dernier écran de son parcours indiquant que son virement ne sera pas exécuté.

• Si présente, la donnée debtor.privateId.identification donne l’identifiant client Banque à Distance saisi par le PSU et fourni au TPP, en vue de faire son authentification auprès de l’ASPSP ; cela évite par conséquent un écran côté IHM ASPSP.
  • Pour les Banques Populaires, la Banque Palatine et la Banque Palatine, il est nécessaire de forcer cette donnée en majuscules.

• La donnée « successfulReportUrl » est obligatoire pour le mode d’authentification REDIRECT mis en œuvre et doit contenir :
  • la redirect URL
  • ainsi que le pkce : code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) + code_challenge_method = S256
  • et le séparateur « & » ( /!\ pas de « ? »)

• Si la donnée « unsuccessfulReportUrl » est renseignée, elle peut contenir le séparateur « & » (pas de « ? » ).

• Si la donnée « unsuccessfulReportUrl » n’est pas renseignée, c’est la donnée valorisée au niveau de « successfullReportUrl » qui sera utilisée

• La donnée supplementaryData doit être alimentée avec la valeur « REDIRECT »

• La donnée scaHint est ignorée pour l’instant => les exemptions d’authentification forte ne sont pas possibles

• Le format autorisé pour la donnée creationDateTime est le format ISO8601.
  • Les trois expressions régulières autorisées sont :
    • YYYY-MM-DDTHH:MM:SS.SSS+HH:MM
    • YYYY-MM-DDTHH:MM:SS.SSS+HHMM
    • YYYY-MM-DDTHH:MM:SS.SSS
  • Z en fin de format signifie que l’heure est en UTC
  • Exemples :
    • 2019-11-12T00:00:00.000+02:00
    • 2019-11-12T00:00:00.000+0200
    • 2019-11-12T00:00:00.000

Déclenchement des parcours fluides

Par défaut, il est demandé au PSU de s’authentifier fortement à deux reprises pour déclencher une demande de paiement. Il est possible de déclencher deux parcours fluides lorsque la requête contient des informations plus précises sur le compte débiteur :

• L’IBAN débiteur (debtorAccount) uniquement : déclenchement de l’identification du PSU avant une authentification forte unique en fin de parcours pour sceller le paiement
• L’IBAN débiteur (debtorAccount) et l’identifiant du PSU (privateId) : déclenchement d’une authentification forte unique en fin de parcours pour sceller le paiement

Notion de cut-off – heure limite pour passer un virement SCT immédiat

Le CUT-OFF correspond à l’heure limite à laquelle un établissement peut exécuter un virement. Cette heure limite prend en compte :

• Les délais de traitement interne
• Les CUTOFF des différents systèmes de compensation, eux-mêmes assujettis au CUT-OFF des différents systèmes de règlement (généralement TARGET2)

Dans le cas des SEPA CREDIT TRANSFER (SCT), l’exécution doit être effectuée au plus tard dans la date de règlement correspondant à la celle demandée par le donneur d’ordre. Il n’est pas permis de reporter cette date de règlement.

En conséquence, lorsque l’heure de CUT-OFF est dépassée, l’exécution est reportée à la date suivante possible. Les dates d’exécution et de règlement sont donc fonction de l’heure d’arrivée de la demande.

L’heure de cut-off pour demander un virement SCT à J avec une date de règlement à J est fixé à 11h00 heure locale française,

L’heure limite pour demander l’exécution d’un virement SCT à J avec une date de règlement à J+1 est fixé à 17h00 heure locale française

Pour rappel, l’heure locale française :

• Egale à GMT +2 pendant l’été,
• Egale à GMT +1 pendant l’hiver

 

HEURE D’ARRIVÉE DE LA DEMANDE INITIALISATION DE PAIEMENT EN HEURE LOCALE FRANÇAISE VALEUR DE CHAMP CREATIONDATETIME	VALEUR DU CHAMP REQUESTE D EXECUTION DATE	RÉSULTAT DE LA PRISE EN COMPTE DE LA DEMANDE D’INITIATION DE PAIEMENT	DATE D’EXÉCUTION	DATE DE RÈGLEMENT
Avant 11h00	Jour J	OK	J	J
Entre 11h00 et 17h00	Jour J	OK	J	J+1
Après 17h00	Jour J	OK	J+1	J+1
Toute heure	>= Jour J+1 ou plus tard	OK	requestedExecutionDate	requestedExecutionDate

Le champ categoryPurpose permet d’empêcher les virements non-marchands vers des bénéficiaires inconnus (non-enregistrés sur la banque en ligne du client) lorsque le moyen d’authentification n’est pas assez fort (hors Secur’pass) : ce champ est nécessaire pour savoir si le paiement est un paiement « à la volée » ou non.

Le champ chargeBearer est obligatoire pour les paiements internationaux (i.e. en devise hors EUR) => les virements internationaux en devise ne sont pas disponibles.

 

Un contrôle additionnel est en place depuis le 7 décembre 2020 afin de rejeter la demande d’initiation de paiement :

• si le bénéficiaire est absent de la liste des bénéficiaires enregistrés par le client dans sa banque en ligne ;
• et si le champ categoryPurpose = « CASH » ou « SALA » ;
• et si le moyen d’authentification forte utilisé n’est pas Secur’Pass.

Cas de rejet injustifié d’un SCT immédiat

Jusqu’à présent, pour les Banques Populaires, une demande d’initiation de paiement pour faire un SCT immédiat (virement pour le jour même) était rejeté les jours non ouvrés (samedi, dimanche, jours fériés, jour fermé au sens TARGET2).

A partir de fin octobre 2020, ces demandes ne seront plus rejetées (pour ce motif du moins) et seront transformé en SCT différé pour le jour ouvré suivant.

 

La banque du bénéficiaire doit être atteignable en Instant Payment.

Pour les Banques Populaires, un client qui s’identifie avec son identifiant ENTREPRISE doit avoir souscrit l’offre IP B2B pour émettre un SEPA Instant Payment. Par ailleurs, la liste des pays atteignables en IP est définie sur le contrat de flux IP B2B et les comptes éligibles au débit figurent doivent aussi être définis sur ce même contrat de flux.

Les SEPA Instant Payment ne sont pas reclassés en SCT immédiat lorsque l’une au moins de ces conditions n’est pas réunie => l’initiation de paiement est rejetée.

 

La donnée numberOfTransactions est à 1 pour un virement unitaire

Les seules valeurs autorisées du champ categoryPurpose sont CASH, SALA et DVPM pour un virement unitaire ;

 

La donnée numberOfTransactions est comprise entre 2 et 50 au plus pour un virement multiple.

Les seules valeurs autorisées du champ categoryPurpose sont CASH et SALA pour un virement multiple.

Un virement multiple n’est possible qu’à une même requestedExecutionDate pour l’ensemble des virements.

La validation du virement multiple par le PSU valide l’ensemble des virements unitaires dont le transactionStatus évolue de la même manière pour l’ensemble des virements unitaires.

Un virement multiple se déboucle en un unique débit du PSU pour l’ensemble des virements unitaires qu’il produit et qui sont traités au même moment : le transactionStatus de tous les virements est le même est vaut « ACSP » ainsi que le paymentInformationStatus.

Si l’un de ces virements unitaires est rejeté par la banque du bénéficiaire, le PSU est recrédité du montant de ce virement et le transactionStatus de ce virement passe à « RJCT », le paymentInformationStatus passe à « PART ».

Si tous ces virements unitaires sont rejetés par la banque des bénéficiaires, le PSU est recrédité du montant total du virement multiple, le transactionStatus de tous les virements unitaires passe à « RJCT » ainsi que le paymentInformationStatus.

Codes erreur

 

Type d’erreur	CODE HTTP	LIBELLÉ	MOTIF
Générique, mauvaise structure	400	Bad request	error code : FF01 message : RJCT
Mauvais format du BIC	400	Bad request	error code : FF01 message : RJCT error : le champ creditorAgent.bicFi bicFi-Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362
Mauvais format du serviceLevel	400	Bad request	error code : FF01 message : RJCT error : value not one of declared Enum instance names: [SEPA, NURG]
Mauvais format, chargeBearer autre que SLEV	400	Bad request	error code: FF01 message: RJCT error: value not one of declared Enum instance names: [SLEV]
Mauvais format du schemeName	400	Bad request	error code: FF01 message : RJCT error : le champ creditor.privateId.schemeName schemeName-Possible values BANK,COID,SREN,DSRET,NIDN,OAUT,CPAN
Mauvais format du purpose	400	Bad request	error code: FF01 message: RJCT error: value not one of declared Enum instance names: [TRPT, CASH, CPKC, ACCT, COMC]
Mauvais format du categoryPurpose	400	Bad request	error code: FF01 message: RJCT error: value not one of declared Enum instance names: [CASH, DVPM]
Mauvais jeton d’accès, problème d’authentification	403	Forbidden
Request resource inconnu	404	Not Found
Mauvaise requête ou requête hors périmètre autorisé	405	Method not allowed
Message générique	500	Internal server error
Requête en doublon	500	Internal server error	error : Problème d’insertion en base de donnée, clé unique dupliquée

 

Récupérer le statut d’une initiation de paiement

Cas d’usage

Cette méthode permet au PISP d’obtenir le statut d’une demande d’initiation de paiement précédemment envoyée à l’ASPSP, pour un PSU donné, via une requête de type POST/payment-requests.

Prérequis

Pour procéder à cette requête il est nécessaire de remplir les prérequis d’éligibilité et d’avoir récupéré le jeton d’accès OAUTH2 (voir la rubrique « Récupérer un jeton« ).

Le TPP a déjà envoyé une requête qui a été enregistrée par l’ASPSP et à laquelle l’ASPSP a répondu avec un lien de localisation vers la demande d’initiation de paiement ou de virement sauvegardée.

Requête GET

Le point d’entrée dépendra du code établissement.

Vous devez insérer la même valeur des paramètres <cdetab> et <banque> que celle utilisée pour le jeton d’accès.

Pour rappel, la liste de nos établissements et les valeurs possibles des <cdetab> et <banque> sont précisées dans la rubrique « Limitations« .

Voici un extrait de cette liste :

 

CODE ÉTABLISSEMENT <CDETAB>	NOM DE L’ÉTABLISSEMENT	NOM ABRÉGÉ	<BANQUE>
13807	B.P Grand Ouest	BPGO	banquepopulaire
10548	Banque de Savoie	BQSAV	banque-de-savoie
40978	Banque Palatine	BPAL	palatine

Comme en mode test, le bon référentiel client est adressable via un « endpoint » au format www.<cdetab>.live.api.89c3.com ou www.<cdetab>.live.api.<banque>.fr

Pour exemple, nous avons donc comme URL de production :

• GET https://www.13807.live.api.89c3.com/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId} ou https://www.13807.live.api.banquepopulaire.fr/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId} pour récupérer le statut d’un paiement pour un client de la BPGO en production

Paramètres obligatoires ou facultatifs du body requis pour l’appel de ce service

Paramètre obligatoire paymentRequestResourceId : identifiant de la requête d’initiation de paiement pour laquelle on souhaite accéder au statut.

Résultat retourné

A la soumission de la requête et si toutes les données sont correctement formatées, une réponse (HTPP 200) vous sera retournée.

Cette réponse contiendra les données de l’initiation de paiement enrichies du statut de la requête d’initiation et du paiement associé.

Les valeurs possibles pour le statut de la demande de paiement sont les suivantes (valeurs pour la version STET v1.6.2.0) :

 

CODE	DESCRIPTION
ACCO	Validation client (AcceptedCustomerCOnfirmed) : Le client a validé l’ordre de paiement
ACCP	Profil Client Accepté (AcceptedCustomerProfile) : La vérification précédente de la validation technique a été réussie. La vérification du profil du client a également été réussie.
ACSC	Règlement accepté terminé (AcceptedSettlementCompleted) : Le règlement sur le compte du débiteur est terminé.
ACSP	Règlement accepté en cours (AcceptedSettlementInProcess) : Toutes les vérifications précédentes, telles que la validation technique et le profil du client, ont abouti. L’évaluation dynamique des risques est également un succès et la demande de paiement a donc été acceptée pour exécution.
ACTC	Validation technique acceptée (AcceptedTechnicalValidation) : L’authentification et la validation syntaxique et sémantique ont réussi.
ACWC	Accepté avec changement (AcceptedWithChange) : Les instructions sont acceptées mais une modification sera apportée, telle que la date ou le versement non envoyé.
ACWP	Accepté sans écriture (AcceptedWithoutPosting) : Les instructions de paiement incluses dans le virement sont acceptées sans être enregistrées sur le compte du client créancier.
CANC	Annulé (Cancelled) : l’initiation de paiement a été annulée après réception d’une requête d’annulation.
PART	Partiellement accepté (PartiallyAccepted) : un certain nombre de transactions ont été acceptées, tandis qu’un autre nombre n’a pas encore atteint le statut «accepté».
PATC	Partiellement accepté (PartiallyAcceptedTechnicalCorrect) : plusieurs authentifications sont nécessaires et certaines ont été effectuées, mais pas toutes. Les vérifications sémantiques et synthaxiques sont correctes
RCVD	Reçu (Received) : le paiement a été initié par l’agent destinataire.
PDNG	En attente (Pending) : Une demande de paiement ou une transaction individuelle incluse dans la demande de paiement est en attente. Des vérifications supplémentaires et une mise à jour du statut seront effectuées.
RJCT	Rejeté (Rejected) : La demande de paiement a été rejetée.

Le tableau suivant reprend les valeurs possibles pour le statut de l’initiation de paiement et de la transaction de paiement associée (valeurs pour la version STET v1.6.2.0) suite à une requête d’initiation de paiement :

 

ETAPE DE TRAITEMENT  D’UNE INITIATION CONTENANT UN PAIEMENT

RÉSULTAT DE L’ÉTAPE	VALEUR DE PAYMENTINFORMATIONSTATUS À L’ISSUE DE L’ÉTAPE	VALEUR DE CREDITRANSFERTRANSACTION / TRANSACTIONSTATUS À L’ISSUE DE L’ÉTAPE
Contrôle et enregistrement de la requête d’initiation (réception et réponse au paymentRequest de l’API DSP2)	OK	ACTC	–
	KO	RJCT	–
Consentement (début consommation de l’URL consentAproval	OK	ACCP	–
	KO	RJCT	–
Demande d’exécution du paiement (juste avant retour REDIRECT vers l’application du TPP)	OK	ACSP (ou PDNG uniquement en environnement sandbox)	PDNG si virement exécuté à J ACSP sinon (forcé à PDNG en environnement sandbox)
	KO	RJCT	RJCT
Si le PSU ne fait aucune action de consentement (validation ou refus) dans les 30 minutes qui suivent la requête d’initiation		RJCT (raison NOAS)	RJCT (raison NOAS)
Jour d’exécution de paiement avant mise à jour du statu la nuit		ACSP	ACSP
Jour d’exécution de paiement après mise à jour du statut la nuit  (hors paiement permanent sauf le jour de sa dernière échéance)	OK	ACSC	ACSC
	KO	RJCT	RJCT
Jour d’exécution de paiement après mise à jour du statut la nuit  (paiement permanent sauf le jour de sa dernière échéance)	OK	ACSP	ACSP
	KO	RJCT	RJCT

Le tableau suivant reprend les valeurs possibles pour le statut de l’initiation de paiement et de la transaction de paiement associée (valeurs pour la version STET v1.6.2.0) suite à une requête d’annulation d’une initiation de paiement :

 

ETAPE DE TRAITEMENT  D’UNE INITIATION CONTENANT UN PAIEMENT

RÉSULTAT DE L’ÉTAPE	VALEUR DE PAYMENTINFORMATIONSTATUS À L’ISSUE DE L’ÉTAPE	VALEUR DE CREDITRANSFERTRANSACTION / TRANSACTIONSTATUS À L’ISSUE DE L’ÉTAPE
Avant réception de la demande d’annulation du paiement		ACTC/ACCP/ACSP	-/PDNG (si paymentInformationStatus = ACSP)
Contrôle et enregistrement de l’annulation de requête d’initiation Juste avant la réponse à la requête d’annulation	OK	RJCT/RJCT/ACSP	-/PDNG (si paymentInformationStatus = ACSP)
	KO	ACTC/ACCP/ACSP	-/PDNG (si paymentInformationStatus = ACSP)
Consentement	OK	ACSP	PDNG
	KO	ACSP	PDNG
Appel au service d’annulation du paiement Juste avant la redirection sur l’application du TPP	OK	CANC (DS02, DUPL, FRAD, TECH)	CANC (DS02, DUPL, FRAD, TECH)
	KO	ACSP	PDNG

Spécificités pour les virements multiples

• La validation du virement multiple par le PSU valide l’ensemble des virements unitaires dont le transactionStatus évolue de la même manière pour l’ensemble des virements unitaires.
• Un virement multiple se déboucle en un unique débit du PSU pour l’ensemble des virements unitaires qu’il produit et qui sont traités au même moment : le transactionStatus de tous les virements est le même est vaut « ACSP » ainsi que le paymentInformationStatus.
• Si l’un de ces virements unitaires est rejeté par la banque du bénéficiaire, le PSU est recrédité du montant de ce virement et le transactionStatus de ce virement passe à « RJCT », le paymentInformationStatus passe à « PART ».
• Si tous ces virements unitaires sont rejetés par la banque des bénéficiaires, le PSU est recrédité du montant total du virement multiple, le transactionStatus de tous les virements unitaires passe à « RJCT » ainsi que le paymentInformationStatus.

Exemples d’évolution du statut du virement

Exemple 1 :

• Une demande d’initiation de paiement est effectuée un jour ouvré à 16h,
• Comme la demande arrive avant 17h, le virement est exécuté le même jour (même si la date de règlement est positionnée à J+1) => un SCT de type immédiat est demandé pour exécution à J,
• La donnée creditTransferTransaction / transactionStatus est positionnée à PDNG dès la validation de l’initialisation du paiement.

Exemple 2 :

• Une demande d’initiation de paiement est effectuée un jour ouvré à 18h,
• Comme la demande arrive après 17h, le virement n’est pas programmé pour être exécuté le même jour => il est transformé en SCT différé et programmé pour le jour ouvré suivant, i.e. à J+1,
• La donnée creditTransferTransaction / transactionStatus est positionnée à ACSP dès la validation de l’initialisation du paiement,
• Le batch journalier de mise à jour du statut des virements qui sont dans un état non terminal est exécuté à 20h00. Ce batch met à l’état PDNG les virements prévu le même jour donc on a :
  • Le jour J de la demande d’initiation du paiement (de sa création à 24h00), le paiement reste à l’état ACSP puisqu’il est programmé pour le jour J+1,
  • A J+1, la donnée creditTransferTransaction / transactionStatus reste à l’état ACSP jusqu’au passage du batch à 20h00. A cette heure-là, la transaction pourrait passer à l’état PDNG
  • Mais comme entre-temps, le virement a été exécuté, il est possible (voire probable) qu’en fait le statut de la transaction soit directement passé de l’état ACSP à l’état ACSC.

Exemple 3 :

• Une demande d’initiation de paiement pour un paiement permanent mensuel est soumise le mercredi 26/02/2020 (2020-02-26T14:00:00.000+02:00) avec :
  • Une requestedExecutionDate le mercredi 04/03/2020 (2020-03-04T14:00:00.000+02:00) ;
  • Une endDate le lundi 04/05/2020 (2020-05-04T14:00:00.000+02:00) ;
  • Un executionRule non alimenté
• Les différents statuts obtenus seraient par exemple

 

DATE DE L’INTERROGATION DU STATUT	ETAPE DE TRAITEMENT DE L’INITIATION CONTENANT UN PAIEMENT	VALEUR DE REQUESTEDEXECUTIONDATE	VALEUR DE PAYMENTINFORMATIONSTATUS ET DE CREDITRANSFERTRANSACTION / TRANSACTIONSTATUS À L’ISSUE DE L’ÉTAPE
2020-02-26T14:00:00.000+02:00	Demande d’exécution du paiement (juste avant retour REDIRECT vers l’application du TPP)	2020-03-04T14:00:00.000+02:00	ACSP / ACSP
2020-02-27T14:00:00.000+02:00	Avant jour 1ère échéance	2020-03-04T14:00:00.000+02:00	ACSP / ACSP
2020-03-04T14:00:00.000+02:00	Jour d’exécution de la 1ère échéance avant mise à jour du statut la nuit	2020-03-04T14:00:00.000+02:00	ACSP / ACSP
2020-03-04T21:30:00.000+02:00	Jour d’exécution de la 1ère échéance après mise à jour du statut la nuit	2020-04-06T14:00:00.000+02:00 (date recalculée le premier jour ouvré, le lundi 6 avril, après l’échéance du 4 avril qui tombe un samedi)	ACSP / ACSP
2020-03-29T14:00:00.000+02:00	Avant jour 2ème échéance	2020-04-06T14:00:00.000+02:00	ACSP / ACSP
2020-03-06T14:00:00.000+02:00	Jour d’exécution de la 2ème échéance avant mise à jour du statut la nuit	2020-04-06T14:00:00.000+02:00	ACSP / ACSP
2020-03-06T21:30:00.000+02:00	Jour d’exécution de la 2ème échéance après mise à jour du statut la nuit	2020-05-04T14:00:00.000+02:00 (date recalculée le lundi 4 mai)	ACSP / ACSP
2020-04-02T14:00:00.000+02:00	Avant jour 3ème et dernière échéance	2020-05-04T14:00:00.000+02:00	ACSP / ACSP
020-04-04T14:00:00.000+02:0	Jour d’exécution de la 3ème et dernière échéance avant mise à jour du statut la nuit	2020-05-04T14:00:00.000+02:00	ACSP / ACSP
2020-04-04T21:30:00.000+02:00	Jour d’exécution de la 3ème et dernière échéance après mise à jour du statut la nuit	2020-05-04T14:00:00.000+02:00	ACSC / ACSC

Exemple 4 :

• Une demande d’initiation de paiement pour un SEPA Instant Payment est effectuée,
• La donnée creditTransferTransaction / transactionStatus est positionnée à ACSP dès la validation de l’initialisation du paiement,Dans les 10 secondes le virement est exécuté et le bénéficiaire est crédité sur son compte après soumission de la requête POST /paymentRequests/confirmation, la donnée creditTransferTransaction / transactionStatus passe à l’état ACSC dans les 20 secondes après la réponse du POST /paymentRequests/confirmation.

Exemple 5 :

• Pour les clients PRO et ENTREPRISE de la Banque Palatine qui utilisent la fonctionnalité du parapheur (Cyber ou mobile) pour valider leurs ordres, les virements SCT immédiats, permanents ou différés qui ont été soumis via une initiation de paiement, ne seront exécutés qu’une fois l’ordre correspondant validé dans le parapheur dans leur banque à distance.
• Après soumission de la requête POST /paymentRequests/confirmation, la donnée creditTransferTransaction / transactionStatus passe à « ACSP ».

Restitution de l’IBAN du compte débité

Depuis fin octobre 2020, l’IBAN du compte débité est systématiquement retourné par cette requête, même si cette donnée n’était pas présente dans la requête initiale de demande d’initiation de paiement.

Exemple

 

GET /stet/psd2/v1.6.2/payment-requests/0000000386-155532845000030007970322

 

Status code : 200

 

Annuler une initiation de paiement

Cas d’usage

Cette méthode permet au PISP d’annuler une demande d’initiation de paiement déjà enregistrée:

• Pour un virement unitaire SCT différé, à condition que le virement n’a pas encore été exécuté et que sa date d’exécution n’est pas atteinte (i.e. date d’exécution prévue au moins à J+1 par rapport à la date de demande d’annulation).

• Pour un virement multiple SCT différé, à condition qu’aucune des virements unitaires n’a encore été exécuté et que sa date d’exécution n’est pas atteinte (i.e. date d’exécution prévue au moins à J+1 par rapport à la date de demande d’annulation).

• Pour un virement unitaire SCT permanent, à condition que la date de l’échéance courante du paiement n’ait pas encore été atteinte (requestedExecutionDate recalculée à chaque fois qu’une échéance du paiement a été traitée) et que sa date de fin (endDate) n’a pas été atteinte (i.e. date d’exécution prévue au moins à J+1 par rapport à la date de demande d’annulation).

Autrement dit, cet appel permet d’envoyer à la banque (ASPSP) d’un client une demande d’annulation d’un virement unitaire ou d’un virement multiple)qui a été initié avec la méthode POST /payment-requests (voir la rubrique « Cas d’usage » > « Initier un paiement« ) et qui n’est pas encore échu.

Seule l’annulation d’un virement unitaire ou multiple SCT différé ou d’un SCT virement unique en euros est possible.

Réciproquement une initiation de paiement pour un virement unitaire ou multiple SCT qui a été initié via l’API DSP2 PISP (quelle que soit la version) est annulable uniquement via l’API DSP2 PISP. Autrement dit, on ne peut pas annuler sur l’application internet de la banque (Cyber) ou sur l’application mobile de la banque, un virement SCT qui a été initialisé via DSP2.

Prérequis

Pour procéder à cette requête il est nécessaire de remplir les prérequis d’éligibilité pour le rôle TPP « PISP » (voir la rubrique « Eligibilité« ), et d’avoir récupéré le jeton d’accès OAUTH2 (voir la rubrique « Vue d’ensemble » > « Récupérer un jeton« ).

Le TPP a déjà envoyé une requête DSP2 API PISP en version 1.6.2 qui a été enregistrée par l’ASPSP et à laquelle l’ASPSP a répondu avec un lien de localisation vers la demande de paiement / virement sauvegardée.

Corollaire :

• Pour annuler une initiation de paiement qui a été initiée par l’API DSP2 en version 1.4.0, il convient d’utiliser une requête DSP2 PISP en version 1.4.0 également (i.e. PUT /stet/psd2/v1/payment-requests/{resourceId}).
• Pour annuler une initiation de paiement qui a été initiée par l’API DSP2 en version 1.4.2, il convient d’utiliser une requête DSP2 PISP en version 1.4.2 également (i.e. PUT /stet/psd2/v142/payment-requests/{resourceId}).

Requête PUT

Le point d’entrée dépendra du code établissement.

Vous devez insérer la même valeur des paramètres <cdetab> et <banque> que celle utilisée pour le jeton d’accès.

Pour rappel, la liste de nos établissements et les valeurs possibles des <cdetab> et <banque> sont précisées dans la rubrique « Limitations« .

Voici un extrait de cette liste :

 

Code établissement <cdetab>	Nom de l’établissement	Nom abrégé	<banque>
13807	B.P Grand Ouest	BPGO	banquepopulaire
10548	Banque de Savoie	BQSAV	banque-de-savoie
40978	Banque Palatine	BPAL	palatine

Comme en mode test, le bon référentiel client est adressable via un « endpoint » au format .live.api.89c3.com » >www.<cdetab>.live.api.89c3.comou .live.api..fr » >www.<cdetab>.live.api.<banque>.fr

Pour exemple, nous avons donc comme URL de production :

• PUT https://www.13807.live.api.89c3.com/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId} ou https://www.13807.live.api.banquepopulaire.fr/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId} pour annuler un paiement pour un client de la BPGO en production

Paramètres obligatoires ou facultatifs du body requis pour l’appel de ce service

Paramètre obligatoire paymentRequestResourceId : identifiant de la requête d’initiation de paiement pour laquelle on souhaite annuler le virement.

La structure du body et les champs obligatoires sont décrits dans la norme STET. Le Tiers de Paiement peut et doit récupérer les informations de son virement avec la méthode GET/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId} afin de vérifier que le paiement est à un statut annulable.

Pour savoir si un virement est éligible les informations suivantes doivent être valorisées dans la requête comme suit :

• La donnée paymentInformationStatus doit avoir l’une des valeurs :
  • ACTC/ACCP/ACSP
• La donnée transactionStatus (au niveau de la transaction dans l’objet creditTransferTransaction) doit avoir la valeur :
  • PDNG (si paymentInformationStatus = ACSP) sinon il ne doit pas être renseigné
• La donnée serviceLevel doit être renseigné à SEPA (seule les virements SEPA différés sont annulables)
• La donnée currency doit être renseignée à EUR => les virements internationaux en devise ne sont pas disponibles
• La donnée frequency ne doit être alimentée que pour les virements permanents.
• La donnée localInstrument ne doit pas être valorisée, seuls les SCT étant acceptés pour l’annulation
• La donnée requestedExecutionDate doit être dans le futur : à minima à J+1

Spécificités pour les virements unitaires

• La donnée numberOfTransactions est à 1 pour un virement unitaire => la requête doit contenir le virement unitaire transmis dans la requête d’initiation de paiement d’origine.

Spécificités pour les virements multiples (cette fonctionnalité sera disponible en février 2023)

• La donnée numberOfTransactions est comprise entre 2 et 50 au plus pour un virement multiple => la requête doit contenir le virement multiple transmis dans la requête d’initiation de paiement d’origine.
• L’annulation d’un virement multiple annule tous les virements unitaires qu’il contient.

Pour permettre à la banque de comprendre que la requête est une demande d’annulation d’une initiation de paiement, certaines informations doivent être modifiées dans la requête comme suit (API DSP2 STET_V1.6.2.0 Part 3 Interaction Examples p.27) :

• La donnée transactionStatus(au niveau de la transaction dans l’objet creditTransferTransaction) doit être positionnée à « CANC » (Annulé)
• La donnée paymentInformationStatus doit avoir la valeur « CANC » (Annulé).
• La donnée statusReasonInformation (au niveau de la transaction dans l’objet creditTransferTransaction) et au niveau de l’initiation de paiement) doit être positionnée avec l’une des valeurs suivantes :

 

statusReasonInformation	Signification
DS02	Annulation à la demande du client
DUPL	Annulation à la demande du PISP en cas de doublon par rapport à un paiement/virement précédent
FRAD	Annulation à la demande du PISP si l’origine du paiement/virement est frauduleux
TECH	Annulation à la demande du PISP pour un problème technique de son côté

• Il faut également enlever toute la partie _links
• Pour finir il faut supprimer l’intitulé du parent « paymentRequest »: { » ainsi que l’accolade fermante en bas du flux « }« 

Les autres données de la requête doivent être identiques à celles récupérées avec la méthode GET.

Résultat retourné

A la soumission de la requête, et si toutes les données sont correctement formatées, une réponse (HTPP 200) vous sera retournée. Cette réponse contiendra le resourceId du paiement, ainsi que le mode d’authentification SCA Redirect (seul mode disponible), l’URL de consentement en fonction de la banque du payeur (urlconsent_approval_URL) et le non rejeu.

Remarques :

• La donnée paymentRequestResourceId, essentielle pour pouvoir annuler un paiement, est incluse en tant que paramètre dans l’URL de consentement « consentApproval » renvoyée lors de l’initiation de paiement.
• Idem pour le non rejeu : c’est le paramètre nonce dans l’URL de consentement.

Codes erreur

 

Type d’erreur	Code HTTP	Libellé	Motif
Générique, mauvaise structure	400	Bad request	error code : FF01 message : RJCT
Mauvais format du BIC	400	Bad request	error code : FF01 message : RJCT error : le champ creditorAgent.bicFi bicFi-Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362
Mauvais format du serviceLevel	400	Bad request	error code : FF01 message : RJCT error : value not one of declared Enum instance names: [SEPA, NURG]
Mauvais format, chargeBearer autre que SLEV	400	Bad request	error code: FF01 message: RJCT error: value not one of declared Enum instance names: [SLEV]
Mauvais format du schemeName	400	Bad request	error code: FF01 message : RJCT error : le champ creditor.privateId.schemeName schemeName-Possible values BANK,COID,SREN,DSRET,NIDN,OAUT,CPAN
Mauvais format du purpose	400	Bad request	error code: FF01 message: RJCT error: value not one of declared Enum instance names: [TRPT, CASH, CPKC, ACCT, COMC]
Mauvais format du categoryPurpose	400	Bad request	error code: FF01 message: RJCT error: value not one of declared Enum instance names: [CASH, DVPM]
Mauvais jeton d’accès, problème d’authentification	403	Forbidden
Request resource inconnu	404	Not Found
Mauvaise requête ou requête hors périmètre autorisé	405	Method not allowed
Message générique	500	Internal server error

 

Exemple

Requête :

PUT /stet/psd2/v1.6.2/payment-requests/00000032fa-159127166900013807464584

Body de Demande d’annulation v1.6.2

Résultat :

Status code : 200

Body de la réponse :

{
« appliedAuthenticationApproach »: « REDIRECT »,
« _links »: {
« consentApproval »: {
« href »: « https://www.13807.live.api.89c3.com/89C3api/accreditation/v1.6.2/cancellation?paymentRequestResourceId=00000032fa-159127166900013807464584&nonce=RFxE0ywQmzW0Z68xJloN&creditorName=QW1hem9uIFNB&creditorAccount=RlI3NjEzODI1MDAyMDAwNDAwMDAwMDQxNzE3&amount=Mi4xMg%3D%3D¤cy=RVVS&successfulReportUrl=aHR0cHM6Ly93d3cuYXBpLjg5YzMuY29tLmZy&unsuccessfulReportUrl=aHR0cHM6Ly93d3cuYXBpLjg5YzMuY29tLmZyL25vdXMtY29udGFjdGVy&debtorAccount=RlI3NjEzODA3MDA4MDQzMDAxOTY1NDA1MTU4&privateId=RDgxODMyNTBJMA%3D%3D&requestedExecutionDate=MjAyMC0wNi0yNFQwOTowMTozMy44NTQrMDI6MDA%3D&method=UFVU »,
« templated »: true
}
}
}

Confirmer une initiation

Cas d’usage

Cette méthode, liée au mode d’authentification dit « redirect », permet au PISP de confirmer à l’ASPSP :

• Soit une demande d’initiation de paiement

• Soit une demande d’annulation d’une initiation de paiement

… en transmettant un facteur d’authentification du titulaire du compte débité afin que l’ASPSP puisse poursuivre la demande.

Seule la méthode POST /payment-requests/{paymentRequestResourceId}/confirmation qui correspond au mode d’authentification dit « redirect renforcé » est implémentée.

Cet appel permet d’envoyer à la banque (ASPSP) d’un client une demande de confirmation d’un paiement qui a été initié avec la méthode POST /payment-requests (voir la rubrique « Cas d’usage » > « Initier un paiement« ) et qui a été validée par le PSU.

Ne sont pas implémentées les méthodes suivantes :

• POST /confirmation du « REDIRECT simple » (renvoie HTTP 405)

• Confirmation d’une annulation de demande de paiement car elle est implicitement portée par l’acceptation par le PSU de la demande d’annulation en elle-même

Prérequis

Pour procéder à cette requête il est nécessaire de remplir les prérequis d’éligibilité pour le rôle TPP « PISP » (voir la rubrique « Eligibilité« ), et d’avoir récupéré le jeton d’accès OAUTH2 (voir la rubrique « Vue d’ensemble » > « Récupérer un jeton« ).

Le TPP a déjà envoyé une requête qui a été enregistrée par l’ASPSP et à laquelle l’ASPSP a répondu avec un lien de localisation vers la demande de paiement / virement sauvegardée après que le PSU a validée le paiement.

Requête POST

Le point d’entrée dépendra du code établissement. Vous devez insérer la même valeur des paramètres <cdetab> et <banque> que celle utilisée pour le jeton d’accès.

Pour rappel, la liste de nos établissements et les valeurs possibles des <cdetab> et <banque> sont précisées dans la rubrique « Limitations« . Voici un extrait de cette liste :

 

Code établissement <cdetab>	Nom de l’établissement	Nom abrégé	<banque>
13807	BP Grand Ouest	BPGO	banquepopulaire.fr
17515	CE Ile de France	CEIDF	caisse-epargne.fr

Comme en mode test, le bon référentiel client est adressable via un « endpoint » au format .live.api.89c3.com » >www.<cdetab>.live.api.89c3.comou .live.api..fr » >www.<cdetab>.live.api.<banque>

Par exemple, nous avons donc comme URL de production :

• POST https://www.17515.live.api.89c3.com/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId}/confirmation

ou

• POST https://www.13807.live.api.banquepopulaire.fr/stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId}/confirmation

Paramètres obligatoires ou facultatifs du body requis pour l’appel de ce service

Paramètre obligatoire paymentRequestResourceId : identifiant de la requête d’initiation de paiement pour laquelle on souhaite confirmer le virement.

La structure du body et les champs obligatoires sont décrits dans la norme STET :

• nonce => challenge à renvoyer par le TPP pour éviter de rejouer le processus d’authentification

• psuAuthenticationFactor => facteur d’authentification transmis par le TPP à la banque pour finaliser le processus d’authentification forte

Le tiers de paiement peut et doit récupérer les informations de son virement avec la méthode GET /stet/psd2/v1.6.2/payment-requests/{paymentRequestResourceId} afin de vérifier que le paiement a été validé par le client :

• La donnée paymentInformationStatus doit avoir la valeur : ACSP

• La donnée transactionStatus (au niveau de la transaction dans l’objet creditTransferTransaction) doit avoir la valeur : PDNG

Cas particulier du parapheur :

Pour les clients PRO et ENTREPRISE de la Banque Palatine qui utilisent la fonctionnalité du parapheur (Cyber ou mobile) pour valider leurs ordres, les virements SCT immédiats, permanents ou différés qui ont été soumis via une initiation de paiement, ne seront exécutés qu’une fois l’ordre correspondant validé dans le parapheur dans leur banque à distance. Les virements SEPA Instant Payment (SCTInst) issus d’une initiation de paiement ne sont pas concernés à ce jour par le parapheur.

Résultat retourné

A la soumission de la requête, et si toutes les données sont correctement formatées, une réponse (HTPP 200) sera retournée.

Cette réponse contiendra le resourceId du paiement, ainsi que le mode d’authentification SCA Redirect (seul mode disponible), l’URL de consentement en fonction de la banque du payeur (urlconsent_approval_URL) et le non rejeu.

Remarques :

• La donnée paymentRequestResourceId, essentielle pour pouvoir confirmer un paiement, est incluse en tant que paramètre dans l’URL de consentement « consentApproval » renvoyée lors de l’initiation de paiement.

• Idem pour le non rejeu : c’est le paramètre nonce dans l’URL de consentement.

Codes erreur

 

Type d’erreur	Code HTTP	Libellé	Motif
Générique, mauvaise structure	400	Bad request	error code : FF01 message : RJCT
Mauvais format du BIC	400	Bad request	error code : FF01 message : RJCT error : le champ creditorAgent.bicFi bicFi-Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362
Mauvais format du serviceLevel	400	Bad request	error code : FF01 message : RJCT error : value not one of declared Enum instance names: [SEPA, NURG]
Mauvais format, chargeBearer autre que SLEV	400	Bad request	error code: FF01 message: RJCT error: value not one of declared Enum instance names: [SLEV]
Mauvais format du schemeName	400	Bad request	error code: FF01 message : RJCT error : le champ creditor.privateId.schemeName schemeName-Possible values BANK,COID,SREN,DSRET,NIDN,OAUT,CPAN
Mauvais format du purpose	400	Bad request	error code: FF01 message: RJCT error: value not one of declared Enum instance names: [TRPT, CASH, CPKC, ACCT, COMC]
Mauvais format du categoryPurpose	400	Bad request	error code: FF01 message: RJCT error: value not one of declared Enum instance names: [CASH, DVPM]
Mauvais jeton d’accès, problème d’authentification	403	Forbidden
Request resource inconnu	404	Not Found
Mauvaise requête ou requête hors périmètre autorisé	405	Method not allowed
Message générique	500	Internal server error

Exemple

Requête :

POST /stet/psd2/v1.6.2/payment-requests/0000000a22-156688979900016807956016/confirmation

Body :

{ « nonce »: « 00000032fa-159127166900013807464584 », « psuAuthenticationFactor »: « azertyui »}

Résultat :

Status code : 200

Body de la réponse :

{

« paymentRequest » : {

« resourceId » : « 0000000a22-156688979900016807956016 »,

« paymentInformationId » : « MyPmtInfld123 »,

« creationDateTime » : « 2019-07-22T09:25:22.527+02:00 »,

« numberOfTransactions » : 1,

« debtorAgent » : {

« bicFi » : « CCBPFRPP512 »,

« name » : « B.P Grand Ouest »,

« postalAddress » : {

« country » : « FR »,

« addressLine » : [

« 15 Boulevard de la Boutière »,

« CS 26858 35768 SAINT GREGOIRE CEDEX »

]

}

},

« initiatingParty » : {

« name » : « MyPispName »,

« postalAddress » : {

« country » : « FR »,

« addressLine » : [

« 5 avenue Anatole France « ,

« 75007 PARIS »

]

},

« organisationId » : {

« identification » : « 12FR5 »,

« schemeName » : « COID »,

« issuer » : « ACPR »

}

},

« paymentTypeInformation » : {

« serviceLevel » : « SEPA »,

« categoryPurpose » : « CASH »

},

« debtor » : {

« name » : « Marc « ,

« postalAddress » : {

« country » : « FR »,

« addressLine » : [

« 512 rue de la coupe du monde »,

« 94512 Charenton-le-Pont »

]

},

« privateId » : {

« identification » : « D0999990I0 »,

« schemeName » : « BANK »,

« issuer » : « BICXYYTT512 »

}

},

« debtorAccount » : {

« iban » : « FR7613807008043001965405255 »

},

« beneficiary » : {

« creditorAgent » : {

« bicFi » : « CCBPFRPP512 »,

« name » : « B.P Grand Ouest »,

« postalAddress » : {

« country » : « FR »,

« addressLine » : [

« 15 Boulevard de la Boutière »,

« CS 26858 35768 SAINT GREGOIRE CEDEX »

]

}

},

« creditor » : {

« name » : « myMerchant »,

« postalAddress » : {

« country » : « FR »,

« addressLine » : [

« Place Charles de Gaulle »,

« 75008 PARIS »

]

},

« organisationId » : {

« identification » : « 852126790 »,

« schemeName » : « BANK »,

« issuer » : « FR »

}

},

« creditorAccount » : {

« iban » : « FR7613807008043001965406128 »

}

},

« purpose » : « COMC »,

« chargeBearer » : « SLEV »,

« paymentInformationStatus » : « PDNG »,

« statusReasonInformation » : null,

« fundsAvailability » : null,

« booking » : null,

« requestedExecutionDate » : « 2020-09-23T13:25:22.527+04:00 »,

« creditTransferTransaction » : [

{

« paymentId » : {

« resourceId » : « 0000000a22-146329369000016907660677 »,

« instructionId » : « MyInstrId123 »,

« endToEndId » : « MyEndToEndId123 »

},

« instructedAmount » : {

« currency » : « EUR »,

« amount » : « 327.12 »

},

« remittanceInformation » : [

« MyRemittanceInformation123 »

],

« transactionStatus » : « PDNG »

}

],

« supplementaryData » : {

« appliedAuthenticationApproach » : « REDIRECT »,

« scaHint » : « scaExemption »,

« successfulReportUrl » : « https://www.api.89c3.com« ,

« unsuccessfulReportUrl » : « https://www.api.89c3.com »

}

}

}

Résultat en cas d’erreur de traitement de la demande (erreur 500):

Status code : 500

Body de la réponse avec détail de l’erreur :
HTTP/1.1 500 Internal Server Error

{

« timestamp »: « 2023-03-07T17:34:20.183+01:00 »,

« status »: 500,

« error »: « Error calling API transfer »,

« message »: « Internal error while performing confirmation »,

« path »: « /stet/psd2/v1.6.2/payment-requests/000001abf7-167820677600013825610187/confirmation »,

« details »: [

{

« message »: « Message sur erreur fonctionnelle »

},

{

« message »: « Operation impossible, veuillez vous rapprocher de votre conseiller. (244) »

},

{

« message »: « bpce.Business »

}

]

}

Autre exemple avec le détail de l’erreur :

HTTP/1.1 500 Internal Server Error

{

« timestamp »: « 2023-03-07T17:34:20.183+01:00 »,

« status »: 500,

« error »: « Error calling API transfer »,

« message »: « Internal error while performing confirmation »,

« path »: « /stet/psd2/v1.6.2/payment-requests/000001abf7-167820677600013825610187/confirmation »,

« details »: [

{

« message »:  » Problème de solde  »

},

{

« message »:  » Le solde de votre compte est insuffisant. »

},

{

« message »: « bpce.balance »

}

]

}

Récupération du détail de l’erreur :Sur la confirmation d’une initiation de paiement PISP 1.6.2, notre API PISP peut fournir une raison plus précise de l’erreur rencontrée auprès du SI de l’ASPSP. Ce détail de l’erreur est contenu dans la donnée de type tableau « details » dans le body de la réponse. Cette donnée de type tableau contient, quand elle est présente, les trois éléments suivants :

 

Indice dans le tableau « details »	Nom du champ	Type de champ	Signification
0	message	string	Description de la catégorie d’erreur. Donne un libellé plus compréhensible de la donnée en indice 2 de ce tableau.
1	message	string	Détail de l’erreur
2	message	string	Code de la catégorie de l’erreur rencontrée

 

Récupérer l'historique d'une initiation de paiement

Ce cas d’usage décrit la méthode GET /payment-requests/{paymentRequestResourceId}/transactions que la norme STET prévoit pour récupérer l’historique d’une demande d’initiation de paiement.Ce cas d’usage décrit la méthode GET /payment-requests/{paymentRequestResourceId}/transactions que la norme STET prévoit pour récupérer l’historique d’une demande d’initiation de paiement.Cette méthode n’est pas disponible. L’appel à cette requête renverra un code HTTP 501.

Assemblage sandbox

Introduction – précisions sur les fonctionnalités de la sandbox

La sandbox BPCE API peut être utilisée directement via l’application du TPP en appelant l’API « Initiation de paiement » de la plateforme BPCE API.

En assemblage sandbox, il y a deux types d’appel :

• Le premier pour récupérer le jeton d’autorisation (voir la rubrique « Vue d’ensemble » > « Récupérez votre jeton« ) ;
• Le second pour faire l’appel à l’API « Initiation de paiement » (voir les cas d’usage « Initier un paiement« , « Récupérer le statut d’une initiation de paiement« , « Confirmer une initiation de paiement » et « Annuler une initiation de paiement »).

Limitations en environnement sandbox :

• Le cas d’usage « Annuler une initiation de paiement », n’est pas totalement testable dans l’environnement sandbox car cette méthode nécessite un croisement des données dynamiques alors que notre sandbox a un comportement statique

• En conséquence, les requêtes d’annulation d’une initiation de paiement sont acceptées dès que le format de la requête est correct (l’identifiant de l’initiation de paiement étant supposé exister).

Votre application consommatrice de l’API « Initiation de paiement » en assemblage sandbox va devoir récupérer un jeton d’accès via sa clé d’authentification auprès de l’AS (Authentification Server).

L’application du TPP consommatrice de l’API « Initiation de paiement » en assemblage sandbox va devoir récupérer un jeton d’accès via sa clé d’authentification auprès de l’AS (Authentification Server).

Ainsi l’application TPP pourra consommer les méthodes « POST /payment-requests« , « GET /payment-requests/{paymentRequestRessourceId}« , « POST /payment-requests/{paymentRequestRessourceId}/confirmation »  et « PUT /payment-requests/{paymentRequestRessourceId} » grâce à son jeton d’accès.

Les appels des méthodes de l’API pourront être enchaînés :

• En exécutant la requête de création du paiement « POST /payment-requests ».
• Puis, en exécutant la requête de récupération du statut du paiement « GET /payment-requests/{paymentRequestRessourceId} en passant en paramètre le « paymentRequestRessourceId » récupéré du résultat de la première requête.
• Puis, en exécutant la requête de confirmation du paiement « POST /payment-requests/{paymentRequestRessourceId}/confirmation » en passant en paramètre le « paymentRequestRessourceId » récupéré du résultat de la première requête.
  
• Puis, en exécutant la requête d’annulation du paiement « PUT /payment-requests/{payementRequestResourceId} » en passant en paramètre le « paymentRequestRessourceId » et le body modifié récupéré du résultat de la seconde requête.

Les données utilisées pour faire les tests seront issues des personas (voir la rubrique « Comment tester l’API ? » > « Testez nos persona« ), ce qui permettra de choisir des profils spécifiques selon les tests de façon à mieux appréhender les résultats obtenus.

Prérequis

Le TPP doit déclarer son APP en sandbox via notre API Register.

Rappel : en tant que TPP, vous devez être accrédité par l’une des autorités compétentes nationales européennes (ACPR en France) pour le rôle d’initiateur de paiement (« PISP »).

Enchaînement des étapes pour tester l’accès à l’API PISP depuis votre APP

1ère étape : Récupérer un jeton d’accès

Cet appel vous permet de récupérer le jeton forgé par la passerelle API de l’ASPSP, et est un prérequis pour chaque accès à l’une des méthodes de l’API d’initiation de paiement.

La description de la fonctionnalité et des champs de la requête est décrite dans la rubrique « Vue d’ensemble » > « Récupérez votre jeton« .

Afin de pouvoir interroger le bon backend dans le parcours client, il est nécessaire que le TPP demande au client au préalable son établissement teneur de compte.

Pour l’accès à l’assemblage sandbox, le point d’entrée dépend du code établissement : www.<cdetab>.sandbox.api.89c3.com

Les seuls établissements bancaires utilisables en assemblage sandbox pour cette API sont les suivants (code établissement <cdetab> utilisé dans les URL) :

 

Code établissement	Nom de l’établissement	Nom abrégé
13807	B.P Grand Ouest	BPGO
17515	Caisse d’Epargne Ile De France	CEIDF

Requête :

POST https://www.13807.sandbox.api.89C3.com/stet/psd2/oauth/token

Dans les headers :

Content-Type : application/x-www-form-urlencoded; charset=utf-8

Dans les params :

client_id : PSDFR-ACPR-12345

grant_type : client_credentials

scope : pisp

 

Remarques sur l’alimentation des champs :

<cdetab> => code établissement des deux banques disponibles dans cet environnement soit :

13807 (Banque Populaire Grand Ouest) ;

17515 (Caisse d’Epargne Ile de France).

client_id :

Si l’enregistrement du TPP a été réalisé au travers du processus de « GoLive » via notre portail BPCE API.

=> numéro d’agrément donné par votre autorité compétente (PSDXX-YYYYYYYY-ZZZZZZZZ)

Ou si l’enregistrement du TPP a été réalisé via l’API registerclient_id retourné dans la réponse au POST /register

=> client_id retourné dans la réponse au POST /register

grant_type => non modifiable = « client_credentials »

Réponse :

{

« access_token » : « firstAccessToken_ABCXdBobTpdwRRaYy2H3w7pP5Xe61e1R9rwxMuhk7G0fULg8x6kJHz »,

« token_type » : « Bearer »,

« expires_in » : « 3600 »,

« scope » : « pisp »

}

Remarques sur l’alimentation des champs :

access_token => tokenCredential à transmettre dans le header authorization des requête de l’API d’initiation de paiement après le Bearer XX.

expires_in => durée de validité du token en secondes.

2ème étape : Initier un paiement

Cet appel vous permet d’initier un paiement en demandant au PSU connecté de donner son consentement pour le paiement.

La description de la fonctionnalité et des champs de la requête est décrite dans le cas d’usage « Initier un paiement« .

Rappel : la méthode d’authentification supportée par l’établissement bancaire est le mode REDIRECT renforcé => les cinématiques des enchaînements des écrans d’identification et d’authentification forte décrites ci-après correspondent à ce mode d’authentification.

 

Requête :

POST https://www.13807.sandbox.api.89C3.com/stet/psd2/v1.6.2/payment-requests

 

Authorization : Bearer firstAccessToken_ABCXdBobTpdwRRaYy2H3w7pP5Xe61e1R9rwxMuhk7G0fULg8x6kJHz

 

Headers :

Content-Type : application/json

Signature : keyId=\ »https://<www.myUrlPath.to>/myQsealCertificate_‎<empreinte-sha256>\« , algorithm=\ »rsa-sha256\ », headers=\ »(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\ », signature=\ »LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1QxiMVg3CmoRM=\ »

X-Request-ID : MyXrequestId123

Body :

Remarques sur l’alimentation des champs :

Authorization : Bearer => access_token récupéré pour le tokenCredential

Les données suivantes devant être unique, sans quoi la requête est rejetée pour cause de doublon (le rejeu n’est pas autorisé) :

– paymentInformationId ;

– instructionId ;

– endToEndId ;

– x-request-id.

debtor/privateId/identification => identifiant d’accès à la banque à distance pour le PSU : lorsqu’il est renseigné et que debtorAccount est renseigné, l’appel à l’écran d’identification du PSU n’est pas effectué.

debtorAccount => IBAN du PSU : lorsqu’il est renseigné, le seul compte sélectionnable pour le PSU est celui qui correspond à cet IBAN, pour peu que le compte soit éligible aux virements PISP. 

Les fonctionnalités mises en œuvre peuvent différer entre les Banques Populaires et les Caisses d’Epargne (cf. cas d’usage « Initier un paiement« ).

Réponse :

{

« appliedAuthenticationApproach » : « REDIRECT »,

« _links » : {

« consentApproval » : {

« href » : »https://www.13807.sandbox.api.89c3.com/89C3api/accreditation/v2/identificationPisp?paymentRequestRessourceId=00000000a22-156688979900016807956016&nonce=qJammuGI0OGCwznaZ0YO”,

« templated » : true

}

}

}

Headers :

X-Request-ID : MyXrequestId123

Status code : 201 OK

Remarques sur l’alimentation des champs :

paymentRequestRessourceId => identifiant à passer à la requête GET /payment-requests pour récupérer le statut de l’initiation de paiement

appliedAuthenticationApproach » = « REDIRECT » => seule valeur autorisée

href => URL de la page de redirection vers les écrans d’identification et d’authentification de l’établissement

nonce => anti rejeu technique

currency => récupérée du body passé en entrée

successfulReportUrl => récupérée du body passé en entrée

unsuccessfulReportUrl => récupérée du body passé en entrée

iban => récupérée du body passé en entrée

creditorName => récupérée du body passé en entrée

X-Request-ID: transmis en entrée

3ème étape : rediriger vers les écrans ASPSP pour que le PSU valide l’opération

Cinématique nominale des enchaînements des écrans d’identification et d’authentification forte

Déroulé de l’enchaînement des écrans d’identification et d’authentification forte :

A partir de l’URI retournée dans « consentApproval« , il est possible de jouer l’enchaînement des écrans.

1) Le PSU est redirigé vers un écran d’identification proposé par son établissement bancaire et dans lequel il saisira son identifiant de banque à distance.

Attention : l’appel à cet écran ne peut être effectué qu’une seule fois

=> le nonce transmis dans l’URL permettant d’accéder à cet écran n’est utilisable qu’une seule fois (il est grillé en suite par l’anti-rejeu)

=> si l’application du TPP ou le PSU ne déroule pas l’ensemble du process en une fois, une nouvelle demande d’initiation de paiement (paymentRequest) sera nécessaire.

L’identifiant de banque à distance du PSU est à saisir (voir rubrique « Comment tester l’API? » > « Tester nos persona » pour les jeux de données de l’établissement), exemple pour le persona « Marc » des Banques Populaires :

Remarque : Le bouton « Mémoriser mon identifiant » n’est pas opérationnel. L’activer ne sert à rien.

Pour les Caisses d’Epargne, si le PSU est un professionnel ou une entreprise, il devra saisir son numéro d’usager en plus de son identifiant de banque à distance.

2) Le PSU est redirigé vers un premier écran d’authentification forte proposé par son établissement bancaire pour valider son identité.

Le code SMS pour authentification est à saisir (voir rubrique « Comment tester l’API? » > « Tester nos persona » pour les jeux de données de l’établissement), exemple pour le persona « Marc » des Banques Populaires:

En production live : La cinématique de cette étape dépend de la méthode d’authentification forte mise à disposition du PSU par l’établissement bancaire (SMS OTP, secur’pass, etc.).

Elle dépend aussi de l’équipement du PSU sur lequel tourne l’application du PISP utilisée par le PSU (PC ou mobile/smartphone/tablette).

Note : en environnement de sandbox, le code SMS à saisir est systématiquement : « 12345678 »

3) Le PSU est redirigé vers un écran de sélection de son compte à débiter proposé par son établissement bancaire.

Exemple de restitution pour le persona « Marc » des Banques Populaires qui dispose de 4 comptes (voir rubrique « Comment tester l’API? » > « Tester nos persona » pour les jeux de données de l’établissement) :

NB : Si le PISP fournit l’IBAN du PSU à débiter dans sa requête (champ « debtorAccount »), seul le compte correspondant sera sélectionnable et proposé au PSU : exemple ci-dessous pour le persona Tech’n Co des Banques Populaires.

NB : Si le PSU ne dispose pas de compte, la requête d’initiation de paiement ne va pas aboutir et le PSU va être redirigé vers votre APP. Exemple pour le persona « Thomas » des Banques Populaires.

4) Le PSU sélectionne et valide le compte à débiter.

5) Le PSU est redirigé vers un second écran d’authentification forte proposé par son établissement pour valider son paiement.

Ecrans identiques à l’écran d’authentification forte de l’étape (2) pour valider l’identité du PSU, hormis l’écran de saisi du mot de passe qui n’est pas représenté.

Des exemptions sont possibles pour l’étape d’AF pour valider le paiement => cette possibilité n’est pas disponible.

Le PISP peut renseigner un indicateur lui permettant d’indiquer qu’il considère la demande de paiement comme étant un cas d’exemption d’authentification forte. La décision finale d’appliquer ou non une exemption d’authentification forte reste à l’appréciation de l’ASPSP.

Les cas de dérogation à l’obligation d’authentification forte du PSU si les exigences générales en matière d’authentification sont remplies sont décrits dans l’article 2 des RTS de la DSP2.

6) Le PSU est redirigé vers l’APP du PISP.

Le PISP fournit lors de sa demande d’initiation une ou deux URL de call back :

La première (successfulReportUrl) sera appelée par l’établissement bancaire dans le cas où la demande d’initiation est traitée et si le PSU a donné son consentement pour le paiement. Un paramètre code est ajouté à la successfulReportUrl.

Exemple : https://<votre SuccessfulReportUrl>?code=GbmTn1ZZ76bibgvCRLxD4lNp8wMzkd

Cette information est importante car nécessaire pour obtenir le token d’accès à la méthode o-confirmation.

La seconde URL (unsuccessfulReportUrl) sera utilisée par l’établissement bancaire en cas de refus du consentement ou si la cinématique de validation de l’initiation de paiement est interrompue à une de ses étapes (exemple : timeout sur l’écran d’identification, sur l’écran de sélection du compte à débiter ou sur les écrans d’authentification forte). Cette seconde URL est facultative : la première URL call back (successfulReportUrl) sera utilisée si la seconde n’est pas renseignée, mais sans ajout de paramètre « code ».

3ème étape alternative : La redirection vers les écrans pour que le PSU valide le paiement en cas de parcours fluides

Cinématique nominale des enchaînements des écrans d’identification et d’authentification forte

Par défaut, il est demandé au PSU de s’authentifier fortement à deux reprises pour déclencher une demande de paiement. Il est possible de déclencher deux parcours fluides lorsque la requête contient des informations plus précises sur le compte débiteur :

• Parcours Fluide Bis : le debtorAccount est renseigné dans la demande d’initation de paiement
• Parcours Fluide : le debtorAccount et le privateId (*) sont renseignés dans la demande d’initation de paiement

 

Parcours Fluide Bis	Parcours Fluide

NB (*) Pour les Caisses d’Epargne, Banque BCP, Crédit Coopératif et BTP Banque et pour les segments de clientèles PRO et ENT : il s’agit du numéro d’abonné séparé du numéro d’usager par un tiret « -« .

Le déclenchement du parcours fluide Bis redirige le PSU vers l’écran de saisie de l’identifiant, c’est le même que dans le parcours classique. L’enchainement qui suit est le même peu importe le type de parcours fluide.

1 ) Le PSU est redirigé vers un écran récapitulatif de l’opération, il peut la valider ou l’annuler

Exemple de restitution pour le persona « Marc » des Banques Populaires qui dispose de 4 comptes dont le compte numéro 30019654051, (voir la rubrique « Comment tester l’API ? » > « Testez nos personas » pour les jeux de données de l’établissement) :

2) Le PSU est redirigé vers un premier écran d’authentification forte proposé par son établissement bancaire pour valider son identité.

Le code SMS pour authentification est à saisir ((voir la rubrique « Comment tester l’API ? » > « Testez nos personas«  pour les jeux de données de l’établissement), exemple pour le persona « Marc » des Banques Populaires:

La cinématique de cette étape dépend de la méthode d’authentification forte mise à disposition du PSU par l’établissement bancaire (mot de passe + SMS OTP, secur’pass, etc.).

Elle dépend aussi de l’équipement du PSU sur lequel tourne l’application du PISP utilisée par le PSU (PC ou mobile/smartphone/tablette).

Note : en environnement de sandbox, le code SMS à saisir est systématiquement : « 12345678 »

3 ) Le PSU est ensuite redirigé vers l’APP du PISP, avec la fourniture du paramètre « code »

4ème étape : Récupérer le statut d’une initiation de paiement

Cet appel GET /payment-requests/{paymentRequestResourceId} vous permet de récupérer l’ensemble des données de l’initiation de paiement enrichies du resourceId et des statuts de l’initiation et du paiement qu’elle contient. La description de la fonctionnalité et des champs de la requête est décrite dans le cas d’usage « Récupérer le statut d’une initiation de paiement« . Les données sont accessibles pendant 35 jours.

Pour l’accès à l’assemblage sandbox, le point d’entrée est identique aux requêtes précédentes :

Requête :

GET https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.6.2/payment-requests/0000000a22-156688979900016807956016

Headers :

Authorization : Bearer firstAccessToken_ABCXdBobTpdwRRaYy2H3w7pP5Xe61e1R9rwxMuhk7G0fULg8x6kJHz

Content-Type : application/json

Signature : keyId=\ »https://<www.myUrlPath.to>/myQsealCertificate_‎<empreinte-sha256>\« , algorithm=\ »rsa-sha256\ », headers=\ »(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\ », signature=\ »LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1QxiMVg3CmoRM=\ »

X-Request-ID : MyXrequestId123

Remarques sur l’alimentation des champs :

Authorization : Bearer => access_token récupéré pour le tokenCredential.

x-request-id => doit être le même que pour la requête d’initiation de paiement

Le paymentRequestResourceId est récupéré en réponse à la requête d’initiation de paiement, lorsque l’initiation de paiement a été traité et que le PSU a donné son consentement pour le paiement.

Réponse :

Headers :

X-Request-ID : MyXrequestId123

Status code : 200 OK

Remarques sur l’alimentation des champs :

resourceId => reprend le paymentRequestResourceId

paymentInformationStatus => reprend le statut de l’initiation de paiement

transactionStatus => reprend le statut de l’opération resourceId

X-Request-ID: transmis en entrée

5ème étape : Confirmer une initiation de paiement (uniquement en production, PAS en sandbox)

Cet appel POST /payment-requests/{paymentRequestResourceId}/o-confirmation vous permet de confirmer une initiation paiement. La description de la fonctionnalité et des champs de la requête est décrite dans le cas d’usage « Confirmer une initiation un paiement« .

La méthode POST /payment-requests/{paymentRequestResourceId}/confirmation n’est pas implémentée.

En préalable à la consommation du service o-confirmation, il est requis d’obtenir un jeton d’accès spécifique via la requête suivante :

Requête :

POST https://www.13807.live.api.89C3.com/stet/psd2/oauth/token

Dans les Headers :

Content-Type : application/x-www-form-urlencoded; charset=utf-8

Dans le body :

grant_type : authorization_code

client_id : PSDFR-ACPR-12345

code : le code récupéré en paramètre de l’appel à la successfulReportUrl en fin d’étape 3

code_verifier : en fonction de vos éléments PKCE

redirect_uri: https://myAPP.fr/Home/OAuth2Callback

Remarques sur l’alimentation des champs :

<cdetab> => code établissement des deux banques disponibles dans cet environnement soit :

13807 (Banque Populaire Grand Ouest) ;

17515 (Caisse d’Epargne Ile de France).

client_id :

Si l’enregistrement du TPP a été réalisé au travers du processus de « GoLive » via notre portail BPCE API :

=> il s’agit du numéro d’agrément donné par votre autorité compétente (PSDXX-YYYYYYYY-ZZZZZZZZ)

OU

si l’enregistrement du TPP a été réalisé via l’API register, client_id retourné dans la réponse au POST /register :

=> il s’agit du client_id retourné dans la réponse au POST /register

redirect_uri : URL de redirection prédéclarée dans votre application consommatrice ET à communiquer à l’ASPSP :

• lors de l’étape GO Assemblage (resp. GO Live en production) si le TPP a été enregistré par la procédure actuelle ;
• via l’API Register si le TPP s’est enregistré par la procédure automatisée.

grant_type => non modifiable = « authorization_code »

Réponse :

{

« access_token » : « secondAccessToken_NBVcxwwmLkjhgfdspoie00OIuyTRPFs »,

« token_type » : « Bearer »,

« expires_in » : « 3600 »,

« refresh_token« : « 1ji8KA9RJ5eXeJV1xKSDj1WDp8wwg3pRgDO2j0WhtbMsWz »,

« scope » : « pisp »,

« state« : « OK-12345 »

}

Remarques sur l’alimentation des champs :

access_token => second token à transmettre dans le header de la prochaine méthode près le Bearer XX.

expires_in => durée de validité du token en secondes.

refresh_token => à mémoriser : permet d’obtenir un nouveau jeton d’accès si le délai de validité du premier jeton est échu (durée de quelques minutes). Le rafraichissement de jeton se fait via le grant-type= refresh_token.

state => L’ASPSP redonne la valeur « state » qui était présente dans la requête initiale de demande d’initiation de paiement (Valeur à la main du TPP).

Une fois le jeton d’accès obtenu, il est possible d’appeler la requête de confirmation de l’initiation de paiement ci-dessous (champ « Authorization »).

Requête:

POST https://www.13807.live.api.89C3.com/stet/psd2/v1.6.2/payment-requests/0000000a22-156688979900016807956016/confirmation

Headers :

Authorization : Bearer secondAccessToken_NBVcxwwmLkjhgfdspoie00OIuyTRPFs

Content-Type : application/json

Signature : keyId=\ »https://<www.myUrlPath.to>/myQsealCertificate_‎<empreinte-sha256>\« , algorithm=\ »rsa-sha256\ », headers=\ »(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\ », signature=\ »LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1QxiMVg3CmoRM=\ »

X-Request-ID : MyXrequestId123

Body :

{

}

Remarques sur l’alimentation des champs :

Authorization : Bearer => second access_token récupéré pour le tokenCredential

{paymentRequestResourceId} : c’est l’identifiant transmis par le service de paiement au moment de l’initiation et qui est utilisé pour le GET

Réponse :
{ « paymentRequest » : {

« resourceId » : « 0000000a22-156688979900016807956016 »,

« paymentInformationId » : « MyPmtInfld123 »,

« creationDateTime » : « 2021-09-05T09:25:22.527+02:00 »,

« numberOfTransactions » : 1,

« debtorAgent » : {

« bicFi » : « CCBPFRPP512 »,

« name » : « Cpy Name »,

« postalAddress » : {

« country » : « FR »,

« addressLine » : [

« 512 rue De Gaulle »,

« 85000 LRSY »

]

}

},

« initiatingParty » : {

« name » : « Pisp Name »,

« postalAddress » : {

« country » : « FR »,

« addressLine » : [

« 512 rue Reaumur »,

« 75512 PARIS »

]

},

« organisationId » : {

« identification » : « 12FR5 »,

« schemeName » : « COID »,

« issuer » : « ACPR »

}

},

« paymentTypeInformation » : {

« serviceLevel » : « SEPA »,

« categoryPurpose » : « DVPM »

},

« debtor » : {

« name » : « Customer Name »,

« postalAddress » : {

« country » : « FR »,

« addressLine » : [

« 512 rue Leclerc »,

« 94512 Charenton-le-Pont »

]

},

« privateId » : {

« identification » : « D0999990I0 »,

« schemeName » : « BANK »,

« issuer » : « BICXYYTT512 »

}

},

« debtorAccount » : {

« iban » : « FR7613807000243021933556300 »

},

« beneficiary » : {

« creditorAgent » : {

« bicFi » : « CCBPFRPP512 »,

« name » : « Creditor Name »,

« postalAddress » : {

« country » : « FR »,

« addressLine » : [

« 512 rue de la primaube »,

« 12512 RODEZ »

]

}

},

« creditor » : {

« name » : « Amazon SA »,

« postalAddress » : {

« country » : « FR »,

« addressLine » : [

« 512 avenue Maupassant »,

« 75512 PARIS »

]

},

« organisationId » : {

« identification » : « 852126790 »,

« schemeName » : « BANK »,

« issuer » : « FR »

}

},

« creditorAccount » : {

« iban » : « FR7613825002000400000541718 »

}

},

« purpose » : « COMC »,

« chargeBearer » : « SLEV »,

« paymentInformationStatus » : « PDNG »,

« statusReasonInformation » : null,

« fundsAvailability » : null,

« booking » : null,

« requestedExecutionDate » : « 2021-09-06T14:10:10.109+01:00 »,

« creditTransferTransaction » : [

{

« paymentId » : {

« resourceId » : « 0000000a22-146329369000016907660677 »,

« instructionId » : « instructionId 1630919339 »,

« endToEndId » : « endToEndId 1630919339 »

},

« instructedAmount » : {

« currency » : « EUR »,

« amount » : « 2.41 »

},

« remittanceInformation »: {

« unstructured »: [

« remittanceInformation01 »

]

},

« transactionStatus » : « PDNG »

}

],

« supplementaryData » : {

« appliedAuthenticationApproach » : « REDIRECT »,

« scaHint » : « scaExemption »,

« successfulReportUrl »: https://extensions.bpce.fr/OAuth2Callback.aspx&state=OK- 12345&code_challenge_method=S256&code_challenge=T3LPv9JWu_HtyEQOkDCo4YYRmZJXTjJ0Ng9jfq_UBBg

}

}

}

Headers :

X-Request-ID : MyXrequestId123

Status code : 200 OK

Remarques sur l’alimentation des champs :

paymentRequestResourceId => identifiant à passer à la requête POST/payment-requests pour confirmer l’initiation de paiement

appliedAuthenticationApproach » = « REDIRECT » => seule valeur autorisée

href => URL de la page de redirection vers les écrans d’identification et d’authentification de l’établissement

nonce => anti rejeu technique

6ème étape : Annuler une initiation de Paiement

Cet appel vous permet d’annuler une initiation paiement en demandant au PSU connecté de donner son consentement pour l’annulation. La description de la fonctionnalité et des champs de la requête est décrite dans le cas d’usage « Annuler une initiation un paiement« .

Rappel : la méthode d’authentification supportée par l’établissement bancaire est le mode REDIRECTsimple => les cinématiques de l’enchaînement de l’écran d’identification et d’authentification forte décrites ci-après correspondent à ce mode d’authentification.

Pour l’accès à l’assemblage sandbox, le point d’entrée est identique : www.<cdetab>.sandbox.api.89c3.com

Requête :

PUT PUT https://www.13807.sandbox.api.89C3.com/stet/psd2/v1.6.2/payment-requests/0000000a22-156688979900016807956016

Headers :

Authorization : Bearer secondAccessToken_NBVcxwwmLkjhgfdspoie00OIuyTRPFs

Content-Type : application/json

Signature : keyId=\ »https://<www.myUrlPath.to>/myQsealCertificate_‎<empreinte-sha256>\« , algorithm=\ »rsa-sha256\ », headers=\ »(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\ », signature=\ »LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1QxiMVg3CmoRM=\ »

X-Request-ID : MyXrequestId123

Body :

Remarques sur l’alimentation des champs :

Authorization : Bearer => second access_token récupéré

{paymentRequestResourceId} : c’est l’identifiant transmis par le service de paiement au moment de l’initiation et qui est utilisé pour le GET

Les données du body doivent être identiques à celles récupérées au moment du GET, à part les suivantes au niveau de la transaction à annuler :

– le transactionStatus de l’objet creditTransferTransaction qui doit être passé à « RJCT »

– le statusReasonInformation de l’objet creditTransferTransaction à « DS02 »

– la partie _links doit être supprimée

– l’enveloppe objet du parent « paymentRequest » : {doit être supprimé, ainsi que l’accolade fermante associée en fin de flux.

Réponse :

{
« appliedAuthenticationApproach »: « REDIRECT »,
« _links »: {
« consentApproval »: {
« href »: « https://www.13807.sandbox.api.89c3.com/89C3api/accreditation/v1.6.2/cancellation?paymentRequestRessourceId=0000000a22-156688979900016807956016&nonce=Ij4VifKlm4QICq12345 »,
« templated »: true
}
}
}

Headers :

X-Request-ID : MyXrequestId123

Status code : 200 OK

Remarques sur l’alimentation des champs :

paymentRequestResourceId => identifiant à passer à la requête GET /payment-requests pour récupérer le statut de l’initiation de paiement

appliedAuthenticationApproach » = « REDIRECT » => seule valeur autorisée

href => URL de la page de redirection vers les écrans d’identification et d’authentification de l’établissement

nonce => anti rejeu technique

currency => récupérée du body passé en entrée

successfulReportUrl => récupérée du body passé en entrée

unsuccessfulReportUrl => récupérée du body passé en entrée

creditorAccount => récupérée du body passé en entrée

creditorName => récupérée du body passé en entrée

amount => récupérée du body passé en entrée

successfulReportUrl => récupérée du body passé en entrée

debtorAccount => récupérée du body passé en entrée

debtorName => récupérée du body passé en entrée

privateId => récupérée du body passé en entrée

requestedExecutionDate=> récupérée du body passé en entrée

method => UFVU est égal à PUT en base64 + URL

X-Request-ID: transmis en entrée

7ème étape : La redirection vers les écrans pour que le client valide l’annulation d’une initiation de paiement

Cinématique nominale des enchaînements des écrans d’identification et d’authentification forte

Déroulé de l’enchaînement des écrans d’identification et d’authentification forte :

A partir de l’URI retournée dans consentApproval il est possible de jouer l’enchaînement des écrans.

1) Le PSU est redirigé vers un écran d’identification proposé par son établissement bancaire et dans lequel il saisira son identifiant de banque à distance.

Attention : l’appel à cet écran ne peut être effectué qu’une seule fois

=> le nonce transmis dans l’URL permettant d’accéder à cet écran n’est utilisable qu’une seule fois (il est grillé en suite par l’anti-rejeu)

=> une nouvelle demande d’annulation de virement DSP2 (via PUT PaymentRequest ) est nécessaire pour récupérer un nouveau jeton nonce si nécessaire.

L’identifiant de banque à distance du PSU est à saisir (voir la rubrique « Comment tester l’API ? » > « Testez nos personas » pour les jeux de données de l’établissement), exemple pour le persona « Marc » des Banques Populaires :

Pour les Caisses d’Epargne, si le PSU est un professionnel ou une entreprise, il devra saisir son numéro d’usager en plus de son identifiant de banque à distance :

2) Le PSU est redirigé vers un écran d’authentification forte proposé par son établissement bancaire pour valider son identité.

Le code SMS pour authentification est à saisir (voir la rubrique « Comment tester l’API ? » > « Testez nos personas » pour les jeux de données de l’établissement), exemple pour le persona « Marc » des Banques Populaires:

La cinématique de cette étape dépend de la méthode d’authentification forte mise à disposition du PSU par l’établissement bancaire (SMS OTP, secur’pass, etc.).

Elle dépend aussi de l’équipement du PSU sur lequel tourne l’APP du PISP utilisée par le PSU (PC ou mobile/smartphone/tablette).

Remarque : en environnement sandbox, le code SMS est systématiquement « 12345678 ».

3) Le PSU est redirigé vers un écran récapitulatif de l’opération en cours d’annulation proposé par son établissement bancaire.

Exemple de restitution pour le persona « Marc » des Banques Populaires veut annuler sa transaction de 2,12 euros émise depuis son Compte Perso. Il peut annuler ou valider son opération d’annulation.

4) Le PSU valide l’annulation du virement.

5) Le PSU est redirigé vers un écran de confirmation de l’opération proposé par son établissement bancaire.

NB : lorsque le PSU ne confirme pas l’annulation de paiement (ou en cas de timeout sur la page récapitulative de l’opération par exemple) le PSU est redirigé vers la page suivante,

6) Le PSU est redirigé vers l’application du TPP PISP.

Le PISP fournit lors de sa demande d’annulation une ou deux URL de call back :

La première (successfulReportUrl) sera appelée par l’établissement bancaire dans le cas où la demande d’annulation est traitée et si le PSU a donné son consentement pour cette annulation d’opération.

La seconde URL (unsuccessfulReportUrl) sera utilisée par l’établissement bancaire en cas de refus du consentement ou si la cinématique de validation de l’annulation de paiement est interrompue à une de ses étapes (exemple : timeout sur l’écran d’identification, sur l’écran récapitulatif de l’opération ou sur les écrans d’authentification forte). Cette seconde URL est facultative : la première URL call back (successfulReportUrl) sera utilisée si la seconde n’est pas renseignée.

NB : la  confirmation d’une annulation d’une demande de paiement ne sera pas implémentée : la confirmation sera implicitement portée par l’acception par le PSU de la demande d’annulation elle-même.

Tester nos personna

Conformément à la réglementation DSP2 (cf. RTS Art. 30 (5)), nous devons en tant qu’ASPSP mettre à disposition un dispositif d’essai comprenant une assistance et permettant des tests de connexion et de fonctionnement, afin que les TPP qui ont demandé l’agrément nécessaire puissent tester les logiciels et applications qu’ils utilisent pour proposer un service de paiement aux utilisateurs.

Cette page présente les jeux de données qui permettent de tester l’API :

Des clients fictifs sont proposés par segment de clientèle (étudiant, cadre, entreprise, etc.) qui recouvrent des cas de clients PART, PRO et ENT :
Le particulier (PART) est une personne physique catégorisée comme « majeur capable ». Le PART peut aussi avoir des activités dans le cadre d’une entreprise individuelle (EI) = une entreprise dirigée par une seule personne, et qui n’a pas de personnalité morale, bien qu’elle soit inscrite au répertoire des métiers ou au Registre du Commerce et des Sociétés (RCS). Exemples : artisan ou profession libérale. Dans ce cas, l’EI est considéré comme un PART.
Les catégories « professionnel » (PRO) et « entreprise » (ENT) couvrent les personnes morales.
Les caractéristiques de leurs comptes et cartes à débit différé y sont déclinées (mono-compte, multi-comptes, multi-bancarisé, présence d’une carte à débit différé, solde du compte)
Les données utiles attendues en entrée par les API y sont énumérées (identifiant banque à distance, code SMS pour les authentifications fortes, IBAN).

Les identifiants et données ci-dessous sont des données fictives et ne peuvent pas être utilisées en production.

Persona Segment Identifiant banque à distance Code SMS pour authentification Code établissement IBAN Numéro de compte Solde Devise – currency
Marc

Cadre

(PART)

D0999990I0 12345678 13807 FR7613807008043001965405158 30019654051 4 321.95 EUR
FR7613807008043001965405255 30019654052 459.56 EUR
FR7613807008043001965405352 30019654053 2 165.50 EUR
FR7613807008043001965405449 30019654054 -232.82 EUR
Marie

Retraité

(PART)

D0999991I0 12345678 13807 FR7613807008043001965406128 30019654061 1 754.03 EUR
FR7613807008043001965406225 30019654062 11 429.00 EUR
FR7613807008043001965406322 30019654063 429.00 EUR
Thomas

Etudiant

(PART)

D0999980 12345678 13807 Pas de compte éligible pour un paiement
Alix

Cadre

(PART)

D0999992I0 12345678 13807 FR7613807008043001965408165 30019654081 -12.35 EUR
FR7613807008043001965408262 30019654082 395.45 EUR
FR7613807008043001965408359 30019654083 298.19 EUR
Tech’n Co

Entreprise

(ENT)

D0999993I0 12345678 13807 FR7613807008043001965409135 30019654091 35 789.78 EUR
Adam

Entrepreneur

(PRO)

D0999994I0 12345678 13807 FR7613807008063031966574122 30319665741 8 008.03 EUR
FR7613807008063031966574219 30319665742 -2 894.05 EUR
Lea

Cadre

(PART)

755238649 12345678 13807 FR7613807008063001965400181 30019654001 11 282.56 EUR
FR7613807008063001965400278 30019654002 527.54 EUR
FR7617515000920400430518020 30019654003 -378.28 EUR
SARL UNIPERSONNELLE 2640

Commerçant

(ENT)

D0999995I0 12345678 13807 FR7613807008063042100847972 30421008479 0.00 EUR
FR7613807008060602191786661 06021917866 139 613 054.35 EUR
FR7613807002353032165639297 30321656392 701 246 591.14 EUR
FR7613807002353092101653050 30921016530 99 792.13 EUR
FR7613807002353092152355047 30921523550 1 015 745.35 EUR
Alienore Cadre (PART) D0990001I0 12345678 13807 FR7613807008043099888880199 30998888801 2 165.5 EUR
FR7613807008043099888880299 30998888802 170.0 EUR
FR7613807008043099888880399 30998888803 3.05 EUR
FR7613807008043099888880499 30998888804 4.15 EUR
FR7613807008043099888880599 30998888805 5.45 EUR
FR7613807008043099888880699 30998888806 6,78 EUR
FR7613807008043099888880799 30998888807 7.6 EUR
FR7613807008043099888880899 30998888808 8.8 EUR
FR7613807008043099888880999 30998888809 9.9 EUR
FR7613807008043099888881099 30998888810 10.10 EUR
FR7613807008043099888881199 30998888811 11.11 EUR
James Employé (PART) D0999996I0 12345678 13807

LU050250065020765162

(Client BCP)

65020765162 1 131.77 EUR

Marc

42 ans – Nantes

Célibataire – Cadre dans la fonction publique – 18 ans d’expérience

4 comptes à vue

Sa vie / Son Histoire / Son travail

Compte à son nom
Actif urbain souhaitant que l’on facilite son quotidien passionné par son travail et ses loisirs

Ses buts

Souhaite acheter et s’installer en centre-ville afin de se rapprocher de ses amis et des associations caritatives dans lesquelles il donne de son temps

Son utilisation

Bon vivant, il utilise le sans-contact à tout va, par téléphone ou par carte
Il possède plusieurs comptes dans le réseau du groupe

Les freins, frustrations potentielles

Il n’aime pas « la paperasse »
La gestion de ses factures pour sa prochaine installation

Ce qui peut l’influencer

Des services simples de gestion des factures et d’alerte crédits
Plus de services en ligne

La bonne surprise

Adepte du smartphone à tout azimut (consultation des comptes, e-commerce, paiement, etc… )

Marie

73 ans – Nantes

Mariée – Retraitée du secteur privée

3 comptes à vue

Sa vie / Son Histoire / Son travail

Mariée, compte à Mme ou Mr
Profite après 40 années de travail d’une retraite bien méritée en voyageant autour du globe avec son mari et sa famille

Ses buts

Souhaite faire plaisir à ses enfants et ses petits-enfants en voyageant avec eux
Souhaite donner plus de son temps pour des actions caritatives

Son utilisation

A part pour quelques achats timides sur internet, Marie à toujours de la monnaie sur elle
Dispose d’un compte joint dans le groupe BPCE

Les freins, frustrations potentielles

Elle n’a pas confiance dans internet
Son smartphone est rarement dans sa poche

Ce qui peut l’influencer

Des services ultra sécurisés, mais qui reste simple d’utilisation

La bonne surprise

Ses enfants et petits enfants lui apprennent la magie des tablettes

Thomas

21 ans – Nantes

Etudiant – Ecole d’ingénieur informatique privée

Pas de compte éligible au paiement

Sa vie / Son Histoire / Son travail

Compte à son nom
Thomas a dû faire un emprunt pour pouvoir payer ses cinq années d’école privée
Depuis qu’il n’est plus en classe préparatoire Thomas a un job étudiant

Ses buts

Terminer rapidement ses études pour pouvoir enfin rentrer dans la vie active
Pouvoir dépenser ce qu’il gagne pour profiter des joies de la vie étudiante

Son utilisation

Il utilise le sans-contact à tout va, par téléphone ou par carte
Thomas fait cependant attention à ce qu’il dépense

Les freins, frustrations potentielles

Ne pas dépasser les plafonds de retrait et de paiement qu’il s’est autorisés
N’aime vraiment pas retenir ses mots de passes

Ce qui peut l’influencer

Des services d’authentification grâce à son smartphone (Touch ID, authentificator, …)
Des alertes en temps réel sur ses dépenses, une visualisation mois par mois

La bonne surprise

Thomas est très porté sur les nouvelles technologies

Alix

32 ans – Nantes

Mariée – 3 enfants

Cadre – Employé du secteur privé

3 comptes à vue

Sa vie / Son Histoire / Son travail

Mariée, compte à Mme ou Mr
Amoureuse de son village d campagne natale, Alix travaille dans la grande ville la plus proche

Ses buts

Souhaite rénover une grande partie de sa maison familiale
Pense déjà aux futurs grandes études de ses enfants, sans oublier les dépenses que cela implique

Son utilisation

Loin de tout les commandes par internet et les livraisons sont son quotidien
Elle se dirige de plus en plus vers des sites chinois

Les freins, frustrations potentielles

La sécurité de ses paiements en ligne
L’assurance de recevoir des produits conforme à ce qu’elle a pu commander
Pas de banque de proximité

Ce qui peut l’influencer

Des assurances pour sécuriser ses paiements
Des plans d’épargne pour assurer la meilleure éducation à ses enfants
Une plus grande proximité avec sa banque

La bonne surprise

Les achats en ligne c’est son dada, tablette ou ordinateur sont ses plus fidèles serviteurs

Tech’n Co

Créée par Dominique – Nantes

37 ans – Mariée – 2 enfants

1 compte à vue

Sa vie / Son Histoire / Son travail

Tech’n Co est une petite entreprise de service informatique, gestion des infrastructures et du réseau dans les PME
Dominique est un entrepreneur actif qui dévoue sa vie à son travail et sa famille

Ses buts

Avoir une vision consolidée de tous ses comptes sur un seul device (smartphone, pc, …)
Continuer de développer son entreprise en atteignant plus de clients
Développer son activité sur d’autres services

Son utilisation

Il s’occupe lui-même de sa trésorerie
Multi bancarisé

Les freins, frustrations potentielles

Suivre les règlements de ses clients suite à la mise en place d’un nouveau service
Garder sa famille à l’abri du besoin

Ce qui peut l’influencer

Des services pour les entreprises simples et bon marché
L’assurance de garder un niveau de vie stable même en cas de coup dur

La bonne surprise

Constamment en déplacement, son application banque ne le quitte jamais

Adam

29 ans – Montpellier

Célibataire – Entrepreneur – 4 ans d’expérience

2 comptes à vue

Sa vie / Son Histoire / Son travail

Adam dirige une société commerciale SARL UNI PICCOLO
Adam est un entrepreneur actif et jeune, il monte en compétence sur son domaine

Ses buts

Avoir accès facilement à l’historique des transactions de ses comptes et cartes
Recruter au sein de sa société
Développer son activité sur d’autres services

Son utilisation

Connexions quotidiennes à ses comptes afin d’avoir un suivi précis
Multi bancarisé

Les freins, frustrations potentielles

A la recherche de solutions technologiques offrant une grande réactivité
La taille de sa société est assez petite

Ce qui peut l’influencer

Des services pour les entreprises simples et bon marché
Pouvoir développer sa société sans prendre trop de risque

La bonne surprise

A la recherche constante de nouvelles solutions digitales

Léa

35 ans – Lyon

Mariée – Cadre chez un assureur – 10 ans d’expérience

3 comptes à vue

Sa vie / Son Histoire / Son travail

Mariée, elle fait beaucoup de randonnées avec son mari
Léa est bien installée dans sa profession et à l’aise dans sa compagnie

Ses buts

Avoir le solde de son compte de façon rapide et sécurisée
Elle souhaite avoir des enfants

Son utilisation

Des achats en ligne réguliers
Très fidèle à sa banque, elle ne veut pas en changer

Les freins, frustrations potentielles

Lenteurs de connexion à son compte
A la recherche d’un minimum de frais bancaires

Ce qui peut l’influencer

Une plus grande proximité avec sa banque
L’accessibilité à son compte depuis n’importe quel endroit

La bonne surprise

Bonne écoute aux conseils apportés par les professionnels du secteur bancaire

SARL UNIPERSONNELLE 2640

Dijon

5 comptes à vue et une carte à débit différé

Sa vie / Son Histoire / Son travail

Commerçant de grande taille

Ses buts

Développer son business de vente en ligne

Son utilisation

Suivi des comptes par un cabinet comptable
Consolidation des comptes dans plusieurs banques

Les freins, frustrations potentielles

Lenteurs de connexion à son compte
A la recherche d’un minimum de frais bancaires

Ce qui peut l’influencer

L’accessibilité à son compte depuis n’importe quel endroit

La bonne surprise

Une situation des comptes accessible en temps réel

Alienor

50 ans – Cadre supérieure

11 comptes à vue

Sa vie / Son Histoire / Son travail

Particulier

Ses buts

Avoir le solde de son compte de façon rapide et sécurisée

Son utilisation

Des achats en ligne réguliers
Très fidèle à sa banque, elle ne veut pas en changer

Les freins, frustrations potentielles

Lenteurs de connexion à son compte
A la recherche d’un minimum de frais bancaires

Ce qui peut l’influencer

Une plus grande proximité avec sa banque
L’accessibilité à son compte depuis n’importe quel endroit

La bonne surprise

Bonne écoute aux conseils apportés par les professionnels du secteur bancaire

James

Luxembourg

1 comptes à vue

Sa vie / Son Histoire / Son travail

Particulier résident au Luxembourg

Ses buts

Avoir le solde de son compte de façon rapide et sécurisée

Son utilisation

Des achats en ligne réguliers
Très fidèle à sa banque, il ne veut pas en changer

Les freins, frustrations potentielles

Lenteurs de connexion à son compte
A la recherche d’un minimum de frais bancaires

Ce qui peut l’influencer

Une plus grande proximité avec sa banque
L’accessibilité à son compte depuis n’importe quel endroit

La bonne surprise

Bonne écoute aux conseils apportés par les professionnels du secteur bancaire

Historique des versions

Version de la norme STET utilisée pour l’API

Cette API REST est conforme à la spécification interbancaire française STET (https://www.stet.eu/en/psd2/), version v.1.6.2.0, afin de répondre aux exigences règlementaires de la DSP2. Elle tient compte des limitations fonctionnelles propres à la Banque de Savoie décrites dans la section « Limitations ».

Pour rappel :

• les textes de la directive de paiement numéro 2 (DSP2, référence UE 2015/2366 du 25/11/2015) sont rentrés en application le 13 janvier 2018 : http://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32015L2366

• ils ont été complétés par les normes techniques de réglementation (NTR, règlement délégué UE 2018/389) relatives à l’authentification forte du client et à des normes ouvertes communes et sécurisées de communication dont la date d’application se situe au 14 septembre 2019. Ces normes sont les RTS (Rules Technical Standards) : https://eur-lex.europa.eu/legal-content/FR/TXT/?toc=OJ%3AL%3A2018%3A069%3ATOC&uri=uriserv%3AOJ.L_.2018.069.01.0023.01.FRA

En France, l’ordonnance n° 2017-1252 du 9 août 2017 transpose la directive DSP2 dans la partie législative du code monétaire et financier. L’ordonnance est complétée au plan réglementaire par les décrets n° 2017-1313 et n° 2017-1314 du 31 août 2017 et les cinq arrêtés du 31 août 2017.

Vous pouvez aussi consulter l’assistant virtuel au sujet des spécifications STET.

Les utilisateurs peuvent également consulter l’assistant virtuel en cliquant sur le pictogramme sur la page d’accueil du portail.

Description du support

Conformément à l’article 30 (5) des RTS, une assistance pour les prestataires PSP tiers est mise à disposition. Ce support utilisateur est accessible via le formulaire sur ce portail BPCE API, ou via https://www.api.89c3.com/fr/nous-contacter. Les réponses se font pendant les heures de travail ouvrées.

Afin d’interroger une API, la version de l’API inclut le numéro de version dans l’URI appelée, soit par exemple : /stet/psd2/v1.6.2/payment-requests.

Le cas d’usage « Roadmap » donne la table de correspondance entre la version de l’API et la version de la spécification utilisée, soit par exemple la v1 de l’API correspond à la version V1.4.0.47 des spécifications STET, la v1.4.2 correspond à la version v1.4.2.17 des spécifications STET et la v1.6.2 correspond à la version v1.4.6.0 des spécifications STET.

Le principe de la durée de support est schématisée ci-dessous en prenant en compte l’article 30 (4) des RTS :

Versionning de l’API

 

Nos versions API	Version norme STET
v1	v1.4.0.47
v1.4.2	v1.4.2.17
v1.6.2	v1.6.2.0

Vous pouvez consulter l’assistant virtuel au sujet des textes de la norme STET.

Evolutions importantes apportées depuis la première version livrée

 

Cas d’usage / Méthode(s)	Date d’effet	Description de l’évolution
POST /payment-requests GET /payment-requests/{paymentRequestResourceId}	17 mai 2019	Documentation portail : Ajout de précisions sur le caractère obligatoire ou facultatif des paramètres et des champs des requêtes.
Toutes	31 juillet 2019	Documentation portail : Description de l’assemblage sandbox en cible à fin août 2019 ; ajouts de précisions (limitations, exemples, date de mise à disposition, etc.) sur l’ensemble des cas d’usage de l’API.
Roadmap	18 septembre 2019	Documentation portail : Roadmap modifiée pour la sandbox et le live.
Eligibilité	1er octobre 2019	Documentation portail : Ajout de précisions sur les certificats QWAC et QSEALC nécessaires pour une demande de goLive.
Initier un paiement	19 novembre 2019	Documentation portail: Ajout de la précision « Pour les Banques de Savoie, la donnée requestedExecutionDate ne peut pas être un week-end ou un jour target 2 pour les SCT »
Comment utiliser le fallback	21 novembre 2019	Documentation portail : Ajout d’un exemple
Récupérer le statut d’une initiation de paiement	9 décembre 2019	Documentation portail : Ajout d’un tableau qui reprend les valeurs possibles pour le statut de l’initiation de paiement et de la transaction de paiement associée.
Tester nos persona	23 décembre 2019	Documentation portail : Précision suivante ajoutée dans le cas d’usage « CES IDENTIFIANTS ET DONNEES DE TEST NE PEUVENT PAS ETRE UTILISES EN PRODUCTION LIVE. » Modification des identifiants banque à distance des persona => ces nouveaux identifiants sont actifs depuis le 8 janvier 2020 (les anciens identifiants sont désactivés)
Initier un paiement	24 décembre 2019	Activation de la prise en compte de l’IBAN transmis dans le champ debtorAccount => IBAN du PSU : lorsqu’il est renseigné, le seul compte sélectionnable pour le PSU est celui qui correspond à cet IBAN.
Historique des versions / roadmap	30 décembre 2019	Documentation portail : Ajout de précisions sur la gestion du versionning et du décommissionnement des API.
Limitations / Historique des versions / roadmap	25 février 2020	Activation de l’API pour les autres BP que BPGO. Modification du versionning de l’API.
Annuler une initiation de paiement / sandbox / limitations	10 septembre 2020	Activation de la méthode d’annulation d’une initiation de paiement.
POST /payment-requests	2 décembre 2020	Documentation portail : Ajout de précisions sur le déclenchement des deux parcours fluides lors d’une initiation de paiement PISP
Initier un paiement / Récupérer le statut d’une initiation de paiement / Sandbox / Roadmap	22 décembre 2020	Depuis le 7 décembre : Activation du parcours PISP fluide ; Rejet des virements avec categoryPurpose = « CASH » lorsque l’AF ne se fait pas avec Sécur’Pass alors que le bénéficiaire n’est pas connu. Si le PSU ne fait aucune action de consentement (validation ou refus) dans les 30 minutes qui suivent la requête d’initiation RJCT (raison NOAS).
Toutes	4 janvier 2021	Documentation portail : Passage de la documentation de l’API DSP2 STET de la version v1 à la version v1.4.2
Toutes	19 juillet 2021	Documentation portail : Activation des initiations de paiement pour les SCT permanents. NB : les annulations des initiations de paiement des SCT permanents ne devraient être disponibles qu’en septembre 2021 Le champ chargeBearer est facultatif pour les virements en euros. Précision sur la gestion des clientId suivant que l’enregistrement du TPP s’est fait via le processus de « GoLive » de notre portail BPCE API via l’API register.
Initier un paiement	22 juillet 2021	Documentation portail : Ajout de la précision sur la limitation de la taille de la donnée beneficiary.creditor.name qui est limitée 35 caractères.
Sandbox / Try-IT	23 septembre 2021	Documentation portail : Ajout de précisions sur la méthode /o-confirmation qui n’est pas disponible en sandbox. Correction des exemples pour la v1.4.2. Suppression de l’écran de confirmation du virement côté ASPSP (écran équivalent à proposer par le TPP après le /o-confirmation)
Initier un paiement	27 septembre 2021	Documentation portail : Ajout de précisions sur le format de l’IBAN et de la donnée debtor.privateId.identification
Toutes	22 mars 2022	Documentation portail : Activation des initiations de paiement pour les SEPA Instant Payments; Correction du double « s » dans « ressourceId » et « paymentRequestResourceId »: Ajout de précisions sur le parapheur pour la Banque Palatine; Mise à disposition du PUT /paymentRequests et du POST /paymentRequests/o-confirmation en sandbox; Ajout de précisions sur le PUT /paymentRequests pour la valorisation des données transactionStatus (= »CANC »), paymentInformationStatus et statusReasonInformation ; Activation des annulations pour les virements permanents.
Initier un paiement / limitations	20 avril 2022	Documentation portail : Ajout de précisions pour les SEPA Instant Payments pour le B2B : les comptes et pays éligibles sont définis sur le contrat de flux IP B2B. Ajout de la précision suivante : un virement initié via l’API d’initiation de paiement, ne peut être annulé par le PSU via son accès direct.
Toutes	26 septembre 2022	Documentation portail : Passage de la documentation de l’API DSP2 STET de la version v1.4.2 à la version v1.6.2 => activation de la v1.6.2 en sandbox le 20 octobre 2022 et en live en janvier 2023. La méthode « o-confirmation » n’est plus supportée => renommée en « confirmation » Ajout des règles pour un virement multiple qui sera disponible en février 2023. Ajout du categoryPurpose = « SALA » : règles alignées sur celles du categoryPurpose = « CASH » La règle suivante : « La donnée requestedExecutionDate ne peut pas être un week-end ou un jour target 2 pour les SCT. Sinon, une erreur est générée et le paiement est rejeté. Cette limitation ne s’applique pas pour les SCT immédiats uniquement si requestedExecutionDate est le jour même de la demande ; dans ce cas, le paiement sera transformé en un SCT différé programmé pour le jour ouvré suivant. » devient « La donnée requestedExecutionDate peut être un week-end ou un jour target 2 pour les SCT : si requestedExecutionDate est le jour même de la demande ; dans ce cas, le paiement sera transformé en un SCT différé programmé pour le jour ouvré suivant. »
Confirmation / Limitations	21 mars 2023	Documentation portail : Restitution du détail des messages d’erreur 500 (Internal Server Error) ajouté en retour de la confirmation d’un paiement. Les clients de la banque BCP auront accès à l’API d’initiation de paiement mi-juin 2023, post migration des agences BCP vers la banque BPALC avec leur IBAN Luxembourgeois : ajout du persona James pour les tests en sandbox.

Roadmap

Politique de décommissionnement des versions de l’API

La politique du décommissionnement (= arrêt d’une version d’une API sur les environnements de production et sandbox) est fonction du cycle de vie des API, et il est prévu une phase de tuilage entre deux versions majeures d’API comme indiqué dans le schéma ci-dessous :

La communication du décommissionnement d’une version N se fera à la date de déploiement de la version N+1. Le canal de communication privilégié est le portail BPCE API dans la partie « Roadmap » de l’API impactée. Une communication via courriel vers les correspondants des prestataires enrôlés sur le portail BPCE API pourra venir compléter ce dispositif.

Planning des évolutions fonctionnelles à venir de l’API

L’API d’Information sur compte fait l’objet d’améliorations et d’évolutions continues tout au long de l’année*.

(*) NB : l’article 30 (4) des RTS précise que des changements significatifs de l’API peuvent intervenir sans délai. Nous appliquons cette clause dans les cas suivants :

• problème bloquant impactant de façon généralisée au moins l’un des segments de clients majeur (particuliers, professionnels, entreprises),
• problème de sécurité,
• évolutions demandées par les autorités nationales compétentes pour répondre à la trajectoire réglementaire.

Retrouvez ci-dessous notre roadmap prévisionnelle.

 

Version de l’API	Version de la norme STET	Fonctionnalités	Sandbox Date de déploiement BPCE API Dev Portal & Sandbox	Live Date de déploiement BPCE Live API Gate way	Date de décommissionnement
v1	v1.4.0.47	Initier un virement unitaire en euros (SCT immédiat / SCT différé) Récupérer le statut d’une initiation de paiement pour un virement unitaire (SCT immédiat / SCT différé)	14 mars 2019 (1ère version) 7 octobre 2019 (mode REDIRECT)	7 octobre 2019	Avril 2023 (à confirmer)
v1	v1.4.0.47	Initier un virement unitaire en euros (SCT immédiat / SCT différé) Récupérer le statut d’une initiation de paiement pour un virement unitaire (SCT immédiat / SCT différé) Annuler une initiation de paiement pour un virement unitaire (SCT différé)	24 août 2020	24 août 2020	Avril 2023 (à confirmer)
v1	v1.4.0.47	Initier un virement unitaire en euros (SCT immédiat / SCT différé) Récupérer le statut d’une initiation de paiement pour un virement unitaire (SCT immédiat / SCT ifféré) Annuler une initiation de paiement pour un virement unitaire (SCT différé) Parcours client fluide pour initier un paiement (1 seule AF si l’identifiant du client, les comptes à débiter et à créditer sont transmis)	7 décembre 2020	7 décembre 2020	Avril 2023 (à confirmer)
v1.4.2	v1.4.2.17	Initier un virement unitaire en euros (SCT immédiat / SCT différé) Récupérer le statut d’une initiation de paiement pour un virement unitaire (SCT immédiat / SCT différé) Annuler une initiation de paiement pour un virement unitaire (SCT différé) Parcours client fluide pour initier un paiement (1 seule AF si l’identifiant du client, les comptes à débiter et à créditer sont transmis) Confirmer une initiation de paiement pour un virement unitaire en euros (SCT immédiat / SCT différé)	30 mai 2021	30 mai 2021
v1.4.2	v1.4.2.17	Initier un virement unitaire en euros (SCT immédiat / SCT différé / SCT permanent) Récupérer le statut d’une initiation de paiement pour un virement unitaire (SCT immédiat / SCT différé / SCT permanent) Annuler une initiation de paiement pour un virement unitaire (SCT différé) Parcours client fluide pour initier un paiement (1 seule AF si l’identifiant du client, les comptes à débiter et à créditer sont transmis) Confirmer une initiation de paiement pour un virement unitaire en euros (SCT immédiat / SCT différé / SCT permanent)	30 juin 2021	30 juin 2021
v1.4.2	v1.4.2.17	Initier un virement unitaire en euros (SCT immédiat / SCT différé / SCT permanent / Instant PaymentPART et B2B) Récupérer le statut d’une initiation de paiement pour un virement unitaire (SCT immédiat / SCT différé / SCT permanent / Instant Payment PART et B2B) Annuler une initiation de paiement pour un virement unitaire (SCT différé / SCT permanent) Parcours client fluide pour initier un paiement (1 seule AF si l’identifiant du client, les comptes à débiter et à créditer sont transmis) Confirmer une initiation de paiement pour un virement unitaire en euros (SCT immédiat / SCT différé / SCT permanent / Instant Payment PART et B2B)	30 mars 2022	30 mars 2022
v1.6.2	v.1.6.2.0	Initier un virement unitaire en euros (SCT immédiat / SCT différé / SCT permanent / Instant Payment PART et B2B) Récupérer le statut d’une initiation de paiement pour un virement unitaire (SCT immédiat / SCT différé / SCT permanent / Instant Payment PART et B2B) Annuler une initiation de paiementv pour un virement unitaire (SCT différé / SCT permanent) Parcours client fluide pour initier un paiement (1 seule AF si l’identifiant du client, les comptes à débiter et à créditer sont transmis) Confirmer une initiation de paiement pour un virement unitaire en euros (SCT immédiat / SCT différé / SCT permanent / Instant Payment PART et B2B)	20 octobre 2022	8 février 2023
v1.6.2	v.1.6.2.0	Initier un virement unitaire en euros (SCT immédiat / SCT différé / SCT permanent / Instant Payment PART et B2B) Récupérer le statut d’une initiation de paiement pour un virement unitaire (SCT immédiat / SCT différé / SCT permanent / Instant Payment PART et B2B) Annuler une initiation de paiement unique pour un virement unitaire (SCT différé / SCT permanent) Parcours client fluide pour initier un paiement (1 seule AF si l’identifiant du client, les comptes à débiter et à créditer sont transmis) Confirmer une initiation de paiement pour un virement unitaire en euros (SCT immédiat / SCT différé / SCT permanent / Instant Payment PART et B2B) Initier un virement mulitiple en euros (SCT immédiat / SCT différé PART et B2B) Récupérer le statut d’une initiation de paiement pour un virement multiple en euros (SCT immédiat / SCT différé PART et B2B) Annuler une initiation de paiement pour un virement multiple (SCT différé) Confirmer une initiation de paiement pour un virement multiple en euros (SCT immédiat / SCT différé PART et B2B)	22 février 2023	22 février 2023

Limitations

Limitations fonctionnelles

Limitations de cette API DSP2 en version 1.6.2

• S’applique à la Banque de Savoie

• Ne s’applique qu’aux comptes de paiements en euros actifs et accessibles en ligne (cf. texte de la Directive PSD2) ;

• N’utilise que le mode d’authentification REDIRECTrenforcé (appel de la méthode confirmation pour que le TPP confirme le paiement après Authentification Forte du PSU demandée et gérée via la banque : l’ASPSP transmet un code d’authorisation OAUTH2 au TPP qui doit le renvoyer à l’ASPSP pour confirmer le paiement)

NB : le TPP n’a pas la possibilité de fournir à l’ASPSP les données de sécurité personnalisées du client à des fins d’authentification, et donc, seuls les écrans de redirection et d’authentification forte (SCA) de l’ASPSP doivent être utilisés (l’encapsulage de ces écrans par le TPP est interdit au regard des articles PSD2 #97.5 et RTS #31)

• Ne traite que les demandes d’initiation de paiement en €uro
  • Donc pas d’initiation de virement en devise
  • Des virements unitaires SEPA SCT de type immédiat, permanent ou différé, ou des SEPA Instant Payment (SCTInst)
  • Des virements multiples SEPA SCT de type immédiat ou différé.

• Le champ chargeBearer est obligatoire pour la méthode POST /payment-requests et doit valoir SLEV, pour les paiements internationaux (i.e. en devise hors EUR) => les virements internationaux en devise ne sont pas disponibles

• Le champ categoryPurpose est obligatoire pour la méthode POST /payment-requests :
  • CASH, SALA et DVPM sont possibles pour un virement unitaire ;
  • CASH et SALA sont possibles pour un virement multiple.

• Les méthodes suivantes sont disponibles :
  • POST /payment-requests et POST /payment-requests/{paymentRequestResourceId}/confirmation pour initier un paiement pour un virement unitaire ou un virement multiple
  • GET /payment-requests/{paymentRequestResourceId} pour récupérer le statut d’une initiation de paiement pour un virement unitaire ou un virement multiple
  • La méthode PUT /payment-requests/{paymentRequestResourceId} n’est supportée que pour annuler une initiation de paiement pour un virement unitaire (virement SCT différé ou permanent) ou un virement multiple (SCT différé).

• La méthode POST /payment-requests/{paymentRequestResourceId}/o-confirmation n’est plus supportée en v1.6.2

• La méthode GET /payment-requests/{paymentRequestResourceId}/transactions n’est pas supportée.

• Identifiant de banque à distance du client de la banque pris en compte (via la donnée debtor/privateId/identification ) pour déclencher un parcours PISP fluide (une seule authentification forte) si le debtorAccountest aussi renseigné dans la requête

• Un virement initié via l’API d’initiation de paiement, ne peut être annulé par le PSU via son accès direct sur la banque en ligne.

• Si aucune action de l’utilisateur n’est effectuée au bout de 30 mns (ou 04 mns sur les écrans de redirection), c’est considéré comme une déconnexion sans redirection en retour vers le TPP

Limitations liées aux segments de clientèle

• Le particulier (PART) est une personne physique catégorisée comme « majeur capable »

• Les catégories « professionnel » (PRO) et « entreprise » (ENT) couvrent les personnes morales

Limitations liées aux types de comptes accessibles

• Les comptes accessibles via l’API PISP à débiter sont ceux disponibles sur la banque à distance pour initier un virement SEPA vers un bénéficiaire externe.

• Il est à noter qu’en adéquation avec la réglementation, l’ASPSP peut appliquer des processus métiers (lutte anti-fraude, etc.) qui peuvent amener à rejeter l’exécution d’une initiation de paiement.

Limitations liées aux moyens d’authentification forte

• Client particulier (PART) : équipement avec Mot de passe + SMS OTP et/ou Sécur’pass (déclenché en priorité le cas échéant)

• Client professionnel (PRO) et entreprise (ENT) : équipement Certificat et/ou Sécur’Pass et/ou lecteur CAP et/ou Mot de passe + OTP SMS

NB : Il n’y a pas d’exemption d’authentification forte (donnée scaHint ignorée)

Accès aux données de production

Conformément à la réglementation, les modes de test Try-it et Assemblage n’utilisent que des données fictives. Ces données de tests sont décrites dans les cas d’usage « Comment Tester l’API ?« .

Pour accéder aux données de production, il est nécessaire d’utiliser notre API d’auto-enrôlement « API Register » (voir la fiche produit dédiée).

La plage hebdomadaire du dimanche matin de 2h à 6h est utilisée si besoin pour la maintenance des backends / des gateways et peut engendrer des requêtes KO le temps que les serveurs concernés aient tous été mis à jour pour l’établissement concerné.

Comme en mode test, le code établissement (voir la liste des établissements bancaires accessibles ci-dessous) vous permettra d’adresser le bon référentiel client via le « endpoint » www.10548.live.api.89c3.com ou www.10548.live.api.banque-de-savoie.fraligné sur le nom de domaine de l’accès directwww.banque-de-savoie.fr

Une fois choisi, ce point d’accès doit être conservé pour toutes les requêtes sous-jacentes.

 

Code établissement	Nom de l’établissement	Nom abrégé	Disponible en Try-it et Assemblage	Disponible en Production
10807	B.P Bourgogne Franche Comté	BPBFC		Oui
16807	B.P AUvergne et Rhône-Alpes	BPAURA		Oui
10207	B.P RIves de Paris + BICS	BPRI		Oui
18707	B.P Val de France	BPVF		Oui
13507	B.P du Nord	BPN		Oui
16607	B.P Sud	BPS		Oui
10907	B.P Aquitaine Centre Atlantique	BPACA		Oui
10907	CMM Littoral du Sud OUest	CMSOU		Oui
14707	B.P Alsace Lorraine Champagne	BPALC		Oui
17807	B.P OCcitane	BPOC		Oui
13807	B.P Grand Ouest	BPGO	Oui	Oui
13807	CMM Grand Ouest	CMMGO	Oui	Oui
14607	B.P MEDiterranée	BPMED		Oui

 

Eligibilité

Les ressources de l’API « Initiation de paiements » ne peuvent être consommées que par des PSP ayant le rôle de Prestataires de Services d’initiation de Paiement (PISP). Ce statut est délivré par les autorités financières du pays dans lequel la demande est effectuée ; en France il s’agit de l’Autorité de Contrôle Prudentiel et de Résolution (ACPR), liée à la Banque de France.

L’obtention et la conservation d’un agrément relèvent de procédures rigoureuses afin d’apporter des garanties fortes aux utilisateurs des services de paiements, les formulaires étant disponibles sur le site de l’ACPR : https://acpr.banque-france.fr/autoriser/procedures-secteur-banque/tous-les-formulaires.

Une fois l’agrément donné, le format de cet identifiant (Organisation Identifier = OID) fourni par l’autorité compétente est :

PSDXX-YYYYYYYY-ZZZZZZZZ:

XX =>code ISO 3166 du pays de l’autorité compétente hyphen-minus « – » (0x2D (ASCII), U+002D (UTF-8))YYYYYYYY => 2-8 caractères du l’identifiant de l’autorité compétente (A-Z, pas de séparateur)hyphen-minus « – » (0x2D (ASCII), U+002D (UTF-8))ZZZZZZZZ => identifiant du PSP spécifié par l’autorité nationale compétente (sans restriction sur le nombre – ou sur le type – de caractère utilisé)

Cet identifiant OID est important à 2 titres :

• il servira à vous identifier lors des appels dans les requêtes des API STET (via le paramètre « client_id »)

• il devra être présent dans les certificats eIDAS que vous fournirez au teneur de compte (voir ci-dessous)

De plus, vous devez disposer de certificats délivrés par une autorité de certification reconnue (Qualified Certification Service Providers – QTSP: https://webgate.ec.europa.eu/tl-browser/#/) conformes au règlement eIDAS (electronic IDentification And trust Services : https://www.ssi.gouv.fr/entreprise/reglementation/confiance-numerique/le-reglement-eidas/) et respectant la norme ETSI (https://www.etsi.org/deliver/etsi_ts/119400_119499/119495/01.02.01_60/ts_119495v010201p.pdf).

Afin de consommer les API DSP2 proposées sur ce portail, le TPP doit enrôler son app et nous transmettre via notre API Register des certificats de production signés par une autorité de certification agréée :

• un premier jeu de certificats QWAC (pour l’authentification mutuelle TLS) et QSEALC (à charger sur notre passerelle via l’API Register) pour la sandbox

• un autre jeu de certificats QWAC (pour l’authentification mutuelle TLS) et QSEALC (à charger sur notre passerelle via l’API Register) pour la production

NB IMPORTANT : en cas de renouvellement de certificat, et si l’autorité de certification (QTSP) est différente (ou c’est la même entreprise QTSP mais qui utilise des clés racines différentes), le TPP doit avertir le support API disponible via ce site de 2 mois avant à toutes fins de vérifier que les élements de la nouvelle autorité de certification sont bien chargés sur nos infrastuctures.

Un identifiant keyID devra aussi être fourni dans un format conforme à la spécification STET intégrant une empreinte SHA256 après le caractère « _ » char, voir exemple dans la documentation STET Part 3 / Interaction Examples : keyId=https://path.to/myQsealCertificate_612b4c7d103074b29e4c1ece1ef40bc575c0a87e.

Seules les clés publiques au format .pem sont nécessaires. Des contrôles sur les données des certificats seront effectués à partir des registres Français (REGAFI : https://www.regafi.fr) et Européen (ABE ou EBA : https://euclid.eba.europa.eu/register/pir/disclaimer).