Banque BCP – 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 de compte à compte (externe).

Via cette API « Initiation de paiement » mise à disposition par l’APSPS, vous pouvez soumettre en temps réel une demande d’initiation du paiement qui se traduira au final par un virement.

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 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 les services d’un TPP afin de réaliser un virement ou un transfert, 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 précise, à travers les interfaces du TPP, le teneur de compte (ASPSP) dans lequel il est domicilié.

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

3- Si le teneur de compte a pu vérifier l’identité et les agréments du prestataire, il pourra 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, le TPP pourra 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 » > « Obtenir le statut« ) ;

• De modifier une initiation de paiement (voir la rubrique « Cas d’usage » > « Annuler une initiation« )

• De confirmer une initiation de paiement (voir la rubrique « Cas d’usage » > « Confirmer une initiation« ).

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 (l’ACPR en France) pour le rôle d’initiateur de paiement (« PISP »).

Pour accéder aux services de l’API d’initiation de paiement, le TPP doit récupérer un jeton d’accès OAUTH2 délivré par l’établissement bancaire du PSU.

A ce titre, le TPP doit s’authentifier mutuellement avec le teneur de compte (ASPSP) par échange de certificats eIDAS QWAC.

Le TPP présentera ensuite ce 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 car le client PSU achète des biens ou des services sur un site e-commerce.

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 TPP 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.

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

Le TPP transmet 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 multiple(cette fonctionnalité sera disponible en février 2023) dans 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 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, le TPP peut annuler 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]

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 :

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.

Utiliser le fallback

Principe

Conformément à la réglementation, les établissements du Groupe BPCE ont mis en place une interface dédiée aux prestataires de services de paiement : il s’agit des API REST DSP2 publiées.

Si l’infrastructure de production « passerelle BPCE API Live » exposant les API DSP2 est défaillante, le prestataire des services de paiements pourra utiliser la solution couvrant les « mesures d’urgence applicables à une interface dédiée » (ou « fallback ») dont le principe est le suivant :

Cette solution répond aux exigences règlementaires de la DSP2 (article 33 des RTS). Vous pourrez l’utiliser avec les mêmes conditions et pré-requis décrits dans la rubrique « Eligibilité« .

Roadmap

Retrouvez ci-dessous les éléments de notre trajectoire prévisionnelle :

(*) Fonctionnalités Principales :

• Utilisation par le TPP du même endpoint que l’interface dédiée.

• Un paramètre de requête (header « fallback:1 » présent ou absent) ajouté par le TPP permet de distinguer une requête « Fallback » d’une requête API via l’interface dédiée qui doit être utilisée systématiquement

• Authentification du TPP via authentification mutuelle TLS par un certificat eIDAS (QWAC)

• Sécurisation identique à celle d’un accès à la banque en ligne du PSU (même interface utilisée par le PSU qu’en accès direct, et mêmes moyens d’authentification du client)

• Dans le cadre de la montée en charge de l’usage de l’interface dédiée (API), il n’est pas mis en place de bascule dynamique : la solution fallback est toujours active

• La solution de fallback est une solution de secours ne devant pas être utilisée comme moyen principal d’accès pour proposer les services DSP2. Son usage en est monitoré et tout usage abusif par un/des TPP sera automatiquement reporté auprès de l’autorité nationale compétente.

Exemple

1. Dans le cas où les API DPS2 sont indisponible de façon imprévue ou le système tomberait en panne (voir critères dans le texte RTS Art. 33), le TPP peut alors envoyer la requête :

POST https://www.17515.live.api.89c3.com/stet/psd2/oauth/token

avec :

• son certificat eIDAS QWAC de production

• le paramètre header (fallback: »1″)

POST /stet/psd2/oauth/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

X-Request-ID: 1234

fallback: 1

User-Agent: PostmanRuntime/7.16.3

Accept: */*

Cache-Control: no-cache

Host: www.17515.live.api.caisse-epargne.fr

Accept-Encoding: gzip, deflate

Content-Length: 67

Connection: keep-alive

client_id=PSDFR-ACPR-12345&grant_type=client_credentials&scope=aisp

2. Si les vérifications sont positives, nous allons vous renvoyer dans le header une url de type à utiliser dans le cadre de la redirection vers l’environnement de la banque en ligne, et qui contient un jeton JWT (champs « &fallback= ») qui doit être aussi utilisé dans ce cadre :

HTTP/1.1 302 Found

Date: Tue, 25 May 2021 21:46:59 GMT

Location: https://www.caisse-epargne.fr/se-connecter/sso?service=dei&cdetab=17515&fallback=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImhF…

Content-Length: 870

Connection: close

Content-Type: text/html; charset=iso-8859-1

</head><body>

<h1>Found</h1>

<p>The document has moved <a >here</a>.</p>

</body></html>

3. Une fois redirigé, le TPP doit utiliser ensuite les identifiants du PSU via sa méthode propriétaire

Pour plus de détails sur la requête POST, voir spécifications STET

Limites

Les contraintes de cette solution sont les suivantes :

• Pas de réutilisation du contexte de l’interface dédiée, ni du jeton d’accès (valable 180 jours actuellement)

• Seules les fonctionnalités DSP2 présentes sur la banque en ligne (référence: banque à distance sur internet fixe) sont accessibles via le fallback. Par exemple, les services de banque en ligne ne proposent pas de paiement e-commerce (cette fonctionnalité PISP n’est donc pas disponible en mode fallback)

• Le client utilisateur des services (PSU) doit être connecté à l’application du TPP (pas de possibilité de traitement batch AISP pour venir récupérer les données consenties du client). La DSP2 imposant également un renforcement des moyens d’authentification forte (AF/SCA) systématique pour les accès à la banque à distance/en ligne, les moyens d’authentification fournis aux clients PSU seront utilisés (liste non exhaustive) :
  • Soft token Sécur’Pass
  • OTP SMS
  • Clé physique (pour les entreprises)

Activer l'App2App

Introduction

Cette fonctionnalité permet d’activer automatiquement l’app bancaire du client à toutes fins d’identification et d’authentification.

Prérequis

Le client doit avoir chargé et utilisé au moins une fois la dernière version de l’application bancaire sur les magasins d’applications Android et Apple (version V6.4.0 et plus).

Note : les segment clients PRO & ENT ne sont pas activés

Le lien de retour (Universal link) doit être définie en avance par le TPP sur le même principe qu’une url de callback :

• si ce lien / cette url a déjà été déclarée sur notre passerelle BPCE API, il n’y a rien d’autre à faire

• sinon le TPP doit le déclarer en utilisant notre API Register

Nos liens « Universal links » ont été déclarés sur les plateformes iOS et Android. Ce n’est pas la peine d’y accéder via par exemple https://www.<codetab>.live.api.caisse-epargne.fr/89C3api/accreditation/v2/.well-known/apple-app-site-association qui renverra une erreur.

Requête

L’activation de la fonctionnalité App2App (webview dans l’app mobile bancaire) s’activera en production après l’envoi d’une série classique de requêtes par l’app du TPP au format STET suivant par exemple pour la Caisse d’Epargne :

• www.<codetab>.live.api.caisse-epargne.fr/stet/psd2/oauth/token

• www.<codetab>.live.api.caisse-epargne.fr/stet/psd2/v1.6.2/payment-requests

• App2App activée via url de redirection fournie par l’ASPSP www.<codetab>.live.api.caisse-epargne.fr/89C3api/accreditation/v2/…

Brand	App2App endpoint
	www.40978.live.api.palatine.fr/stet/psd2/oauth/token www.40978.live.api.palatine.fr/stet/psd2/v1.6.2/payment-requests App2App activée via url de redirection fournie par l’ASPSP www.40978.live.api.palatine.fr/89C3api/accreditation/v2/…
	www.<codetab>.live.api.banquepopulaire.fr/stet/psd2/oauth/token www.<codetab>.live.api.banquepopulaire.fr/stet/psd2/v1.6.2/payment-requests App2App activée via url de redirection fournie par l’ASPSP www.<codetab>.live.api.banquepopulaire.fr/89C3api/accreditation/v2/… (voir la liste des <codetab> sur la fiche produit API Banque Populaire)
	www.10548.live.api.banque-de-savoie.fr/stet/psd2/oauth/token www.10548.live.api.banque-de-savoie.fr/stet/psd2/v1.6.2/payment-requests App2App activée via url de redirection fournie par l’ASPSP www.10548.live.api.banque-de-savoie.fr/89C3api/accreditation/v2/…
	www.<codetab>.live.api.caisse-epargne.fr/stet/psd2/oauth/token www.<codetab>.live.api.caisse-epargne.fr/stet/psd2/v1.6.2/payment-requests App2App activée via url de redirection fournie par l’ASPSP www.<codetab>.live.api.caisse-epargne.fr/89C3api/accreditation/v2/… (voir la liste des <codetab> sur la fiche produit API Caisse d’Epargne)
	www.12579.live.api.banquebcp.fr/stet/psd2/oauth/token www.12579.live.api.banquebcp.fr/stet/psd2/v1.6.2/payment-requests App2App activée via url de redirection fournie par l’ASPSP www.12579.live.api.banquebcp.fr/89C3api/accreditation/v2/…
	www.42559.live.api.credit-cooperatif.coop/stet/psd2/oauth/token www.42559.live.api.credit-cooperatif.coop/stet/psd2/v1.6.2/payment-requests App2App activée via url de redirection fournie par l’ASPSP www.42559.live.api.credit-cooperatif.coop/89C3api/accreditation/v2/…
	www.30258.live.api.btp-banque.fr/stet/psd2/oauth/token www.30258.live.api.btp-banque.fr/stet/psd2/v1.6.2/payment-requests App2App activée via url de redirection fournie par l’ASPSP www.30258.live.api.btp-banque.fr/89C3api/accreditation/v2/…
	www.18919.live.api.natixis.com/stet/psd2/oauth/token

Sinon, une webview sur le navigateur du smartphone du client sera affichée dans les cas suivants :

• si l’app bancaire n’est pas chargée sur le smartphone du client

ou

• si l’app bancaire chargée n’est pas compatible avec l’App2App (voir les prérequis)

ou

• si l’autre format d’appel des point d’accès a été utilisé www.<codetab>.live.api.89c3.com/stet/psd2/oauth/token(ce qui peut être utile comme backup en cas de problème avec l’App2App)

Publications réglementaires

/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

Codes retour

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

Codes retour

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

Codes retour

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

Codes retour

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

Codes retour

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 en € !

Contexte

Cet appel permet au TPP d’envoyer à la banque (ASPSP) d’un client une demande d’initiation de paiement venant débiter son compte via un virement. S’il s’agit d’une initiation de paiement initiée par un e-commerçant (pas par le client final), le virement 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.

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 ressourceId 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.

Différents types de virements sont disponibles (SCT Core immédiat, différé, permanent, instantané, mutiple), voir la section « Limitations« .

Attention : toutes les demandes d’initiation de paiement ne se concluent pas automatiquement par un virement car des règles de gestion s’appliquent et peuvent rejeter la demande PIS (par exemple : règles bancaires, lutte anti-fraude, etc…). Un code STET est retouné dans ces cas.

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 du paramètre <cdetab> que celle utilisée pour le jeton d’accès.

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

Pour exemple, nous avons donc comme URL pour initier en production un paiement pour un client du teneurs de compte :

POST https://www.<cdetab>.live.api.89c3.com/stet/psd2/v1.6.2/payment-requests

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ée à « SEPA »

• La donnée amount doit être renseignée avec une valeur conforme aux montants min/max tels qu’appliqués sur la banque en ligne, et qui peuvent être différents par ASPSP et/ou par type d’opération demandée (SCT CORE ou INST) et/ou par segment client

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

• Seuls les IBAN sont supportés pour les données Iban, debtorAccount et creditorAccount

• La donnée numberOfTransactions doit être valorisée (voir les valeurs possibles dans les paragraphes ci-dessous)

• La donnée frequency doit être valorisée que pour les virements SCT permanent (voir les valeurs possibles dans les paragraphes ci-dessous)

• 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
  • La banque du bénéficiaire doit être atteignable en SCT Inst
  • Pour les clients professionnels et entreprises, il faut que les les comptes émetteurs et les pays des bénéficiaires éligibles pour ce type de virement sont définis sur le contrat de banque en ligne.

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

• La donnée successfullReportUrl 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 unsuccessfullReportUrl 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

• La donnée state est obligatoire pour le mode d’authentification REDIRECT mis en œuvre car elle est propagée durant tout le parcours PISP

• Le champ endToEndId ne doit pas être vide
• Le champ chargeBearer est obligatoire pour la méthode POST /payment-requests, et il doit avoir la valeur « SLEV »
• 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 niveau du moyen d’authentification utilisé par le client n’est pas assez élévé pour effectuer cette opération (hors Secur’pass): ce champ est nécessaire pour savoir si le paiement est un paiement « à la volée » ou non, et est obligatoire pour la méthode POST /payment-requests.Il doit avoir la valeur « CASH » (opération de compte à compte) ou « SALA » (virement de salaire) ou « DVPM » (opération e-commerce) générant des règles de gestion différentes (voir ci-dessous)

• Le champ requestedExecutionDate doit avoir une date supérieure à la date de demande d’initiation de paiement creationDateTime

• La donnée facultative debtor.privateId.identification peut être renseignée avec le numéro abonné du PSU utilisé pour son accès direct (et avec des majuscules si un/des caratères alphanumériques sont présents)

• Le champ creationDateTime ne doit pas être vide, et rempli comme le précédent avec une des trois expressions régulières autorisées au format ISO8601 :

YYYY-MM-DDTHH:MM:SS.SSS+HH:MM

YYYY-MM-DDTHH:MM:SS.SSS+HHMM

YYYY-MM-DDTHH:MM:SS.SSS

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

Il est possible de déclencher un parcours fluide (avec deux variations) lorsque la requête contient des informations plus précises sur le débiteur :

• Si seul l’IBAN débiteur (debtorAccount) est fourni : déclenchement de l’identification du PSU avant une authentification forte unique en fin de parcours pour sceller le paiement

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

Heure limite pour 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 CUT-OFF des différents systèmes de compensation interbancaires, 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 à celle demandée par le donneur d’ordre. Il n’est pas permis de reporter cette date de règlement sauf lorsque l’heure de CUT-OFF est dépassée, l’exécution étant reportée à la date suivante possible (non fériée). Les dates d’exécution et de règlement sont donc fonction de l’heure d’arrivée de la demande d’initiation de paiement.

Pour cet ASPSP, le CUT-OFF pour demander un virement SCT à J avec une date de règlement à J est fixé à 13h30 heure locale française.

Pour rappel, l’heure locale française est égale à :

• GMT+2 pendant l’été

• GMT+1 pendant l’hiver

Cas du SCT unitaire

La requête doit contenir une demande d’initiation pour un seul paiement (pas de paiement multi-bénéficiaire) :

• la donnée numberOfTransactions doit être valorisée à « 1 »
• La donnée requestedExecutionDate doit être égale ou supérieure à la date du jour

Cas des SCT différé et permanent

La date d’exécution (donnée requestedExecutionDate) d’un virement différé (ou de la première échéance d’un virement permanent) doit être positionnée au-delà de J + 72 heures, sinon la demande sera rejetée.

Pour le SCT permanent, les fréquences (donnée frequency) possibles sont :

• hebdomadaire
• bi-mensuelle
• mensuelle
• trimestrielle
• semestrielle
• annuelle

La date de dernière échéance (donnée endDate) doit aussi être renseignée et doit correspondre à une échéance valide dans le futur.

Cas des SCT multiples

Ce type d’opération correspond à un virement d’un compte débiteur professionnel ou entreprises vers N comptes bénéficiaires. Cela se traduira ultimement par N virements unitaires vers les IBAN créditeurs.

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

Les seules valeurs autorisées du champ categoryPurpose sont « CASH » et « SALA ».

Un virement multiple n’est possible qu’avec la même requestedExecutionDate pour l’ensemble des virements (mono-date d’éxécution, pas de multi-date).

La validation du virement multiples 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.

Si toutes les conditions sont réunies, un virement multiple se déboucle en un débit unique du PSU correspondant au montant de l’ensemble des virements unitaires produits et qui sont traités au même moment : le transactionStatus de tous les virements sera le même, ainsi que le paymentInformationStatus.

Si l’un de ces virements unitaires est rejeté par l’ASPSP avant compensation, l’ensemble du virement multiple est rejeté et le transactionStatus de ce virement passe à « RJCT », le paymentInformationStatus passe à « PART ».

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 multiples, le transactionStatus de tous les virements unitaires passe à « RJCT » ainsi que le paymentInformationStatus.

Contrôle sur le bénéficiaire

Un contrôle additionnel est en place 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é par le PSU n’est pas le plus sécuritaire (Sécur’Pass ou certificat physique)

Codes erreur

Obtenir le statut

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, et pour un PSU donné.

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’initation de paiement ou de virement sauvegardée.

Requête

GET /payment-requests/{paymentRequestResourceId}

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) 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é telles que définies dans la spécification STET version v1.6.2.0.

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

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

Restitution de l’IBAN du compte débité

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.

Codes erreur

Annuler une initiation

Cas d’usage

Cette méthode permet au PISP d’annuler une demande d’initiation de paiement déjà enregistrée, à condition que le paiement n’ait 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).

Autrement dit, cet appel permet d’envoyer à la banque (ASPSP) d’un client une demande d’annulation 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 n’est pas encore échu.

Pour cet ASPSP, un virement SCT qui a été initié via l’API DSP2 PISP (quelle que soit la version) est annulable via l’API DSP2 PISP ou directement par le PSU via son application web ou mobile.

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 « Cas d’usage » > « Récupérer un jeton« ).

Le TPP a déjà envoyé une requête DSP2 API PISP 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.6.2, il convient d’utiliser une requête DSP2 PISP en version 1.6.2 également (i.e. PUT /stet/psd2/v1.6.2/payment-requests/{resourceId}).

Requête

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

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

Par exemple, voici la requête pour annuler en production un paiement pour un client de la CEIDF :

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

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.

En préalable, le Tiers de Paiement 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 (seuls les virements SCT différé et permanent sont annulables)

• La donnée currency doit être renseignée à EUR

• La donnée localInstrument ne doit pas être valorisée

• La donnée requestedExecutionDate doit être dans le futur : à minima à J+1

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.23) :

• La donnée transactionStatus (au niveau de la transaction dans l’objet creditTransferTransaction) doit être positionnée à « RJCT » (Rejeté)

• La donnée statusReasonInformation (au niveau de la transaction dans l’objet creditTransferTransaction) doit être positionnée avec l’une des valeurs suivantes :

• 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.

Cas du SCT Récurrent

L’initiation d’un paiement récurrent peut être annulée tant qu’elle est en cours de traitement (ACSP) jusqu’à l’exécution du dernier paiement.

Si tous les paiements ont été exécutés, l’initiation d’un paiement récurrent est impossible à annuler.

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 ressourceId 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 paymentRequestRessourceId, 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

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 :

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

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 :

Assemblage Sandbox

Introduction

La sandbox BPCE API peut être accédée directement via votre application : c’est le mode assemblage.

Cet ASPSP étant sur le même système d’information bancaire que les Caisses d’Epargne (CE), le format des données retournées via API sera identique.

Vous pouvez donc utiliser l’environnement de sandbox des CE (et leurs données) tel que décrit dans le cas d’usage « https://www.api.89c3.com/fr/component/bpceportal/products/753/usecases/742« .

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 à l’ASPSP telles que 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.

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 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.

Le principe général du support est schématisé ci-dessous en prenant en compte les délais réglementaires prévus à l’article 30 (4) des RTS :

Versionning de l’API

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

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.

Limitations

Limitations fonctionnelles

Limitations de cette API DSP2

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

• N’utilise que le mode d’authentification REDIRECT renforcé avec confirmation (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 euro (PAS d’initiation de virement en devise)
  • SCT Core unitaire de type immédiat ou différé ou permanent pour les segments de clients PART/EI/PRO/ENT
  • SCT Core multiple de type immédiat (PAS de multi-dates) pour les segments de clients PRO/ENT d’un compte débiteur vers N créditeurs résultant en N opérations avec différents montants possibles, et que pour les types de categoryPurpose = « CASH » et « SALA »
  • SCT INST pour les segments de clients PART/EI/PRO/ENT

• Le BIC Creditor n’est pas nécessaire SAUF pour les opérations PIS hors zone SEPA (toujours en euro)

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

NB : Les méthodes suivantes ne sont PAS supportées : POST /payment-requests/{paymentRequestRessourceId}/o-confirmation et GET /payment-requests/{paymentRequestRessourceId}/transactions

• L’annulation d’une demande de virement unitaire (hors SCT Inst et virement multiple) via API PIS peut être effectuée :
  • par le PSU via son accès direct avant une heure limite
  • par le TPP via API avant une heure limite

• Les demandes PIS de type « CASH » et « SALA » seront rejetés si le PSU n’utilise pas un moyen d’authentification forte ayant un niveau suffisemment sécuritaire (Secur’Pass ou le certificat sur clé physique pour les PRO & ENT), et si l’IBAN bénéficiaire n’est pas enregistré au préalable sur son accès direct

• Différentes demandes PIS ayant les mêmes caractéristiques qu’une préalablement executée (même jour, même IBAN debiteur et créditeur, même montant, etc…) sont rejetées (fonctionnement identique à la banque en ligne)

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

• Si le PSU a plusieurs IBAN liés à un même abonnement, le nombre maximum de comptes de paiements éligibles DSP2 affichés lors du parcours classique est limité à 10 lignes

• La longueur du champs creditor.name est limitée à 32 caractères

Limitations liées aux types de comptes accessibles

• Les comptes accessibles via l’API PISP sont ceux disponibles sur la banque à distance éligibles DPS2 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 segments de clientèle

Sont couverts par l’API les segments clients suivants :

• Client « particulier » (y compris compte joint et mineur rattaché) ayant un abonnement à la banque en ligne « BCP Net » et un compte commençant par 04

NB 1 : 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 le statut de « persone 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

NB 2 : est non compris à ce jour le tuteur de personne protégée/sous tutelle ou curatelle utilisant la solution Web Protexion

• Client « gros professionnel », « entreprise » et « association » ayant un abonnement à la banque en ligne « BCP Net » et un compte commençant par 08 autorisant les virements unitaires

NB 3 : les catégories « entreprise » (ENT) et « association » (ASSOC) couvrent les personnes morales

Limitations liées aux moyens d’authentification forte

Il est de la responsabilité de l’ASPSP d’équiper ses clients avec un ou des moyens d’authentification forte :

• PART : Accès aux comptes PART et Opération sensible / Dynamic linking (DL) : (Sécur’Pass) ou (lecteur CAP) ou (Mot de Passe + OTP SMS)

• PRO/ENT : Accès aux comptes PART et Opération sensible / Dynamic linking (DL) : (certificat matériel) ou (Sécur’Pass) ou (lecteur CAP) ou (Mot de Passe + OTP SMS)

NB 4 : il n’y a pas d’exemption de la seconde authentification forte AF/SCA dynamic linking (donnée scaHint ignorée)

NB 5 : il y aura un rejet des virements avec categoryPurpose = « CASH » ou « SALA » lorsque l’AF/SCA DL ne se fait pas avec le moyen principal et que l’IBAN bénéficiaire n’est pas enregistré par le PSU sur sa banque en ligne

NB 6 : le certificat matériel n’est pas proposé aux client sur mobile/smartphone

Accès aux données de production

Conformément à la réglementation, les modes de test d’assemblage (sandbox) n’utilisent que des données fictives qui sont décrites dans le cas d’usage « Comment Tester l’API ?« .

Pour accéder aux données de production, l’utilisation de l’API REGISTER est un prérequis (voir la fiche www.api.89c3.com/fr/component/bpceportal/products/522/usecases/523).

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.<cdetab>.live.api.89c3.com (ou www.<cdetab>.live.api.banquebcp.fr aligné sur le nom de domaine de l’accès direct www.banquebcp.fr).

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

NB : la plage hebdomadaire du lundi matin de minuit à 06h00 est utilisée pour la maintenance des infrastructures des systèmes d’information (tous composants, y compris le système central/backend, les passerelles, etc…) et peut engendrer des requêtes API en erreur ou des indisponibilités le temps des interventions (de même pour des traitements bancaires programmés en début et fin de journée/mois/trimestre/année).

(*) Cet ASPSP étant sur le même système d’information que les Caisses d’Epargne (CE), le format des données retournées via API sera identique. Vous pouvez donc utiliser les données CE en sandbox tel que décrit dans le cas d’usage « Comment tester l’API ? ».

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).