➤ 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 les API DSP2 exposées sont défaillantes, 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 :

Version	Fonctionnalités	Sandbox Date de déploiement 89C3 API Dev Portal & Sandbox	Live Date de déploiement 89C3 Live API Gateway
v1.0	Fallback (*)	Non applicable	Fin Septembre 2019

(*) Fonctionnalités Principales :

• Utilisation par le TPP du même endpoint que l’interface dédiée. Il dépend donc du code établissement <cdetab> qui permet d'adresser le bon référentiel client.

• 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.12579.live.api.89c3.com/stet/psd2/oauth/token

avec :

• son certificat eIDAS QWAC de production

• le paramètre header (fallback:"1")  

2. Si les vérifications sont positives, la page d'accès à la banque en ligne s'affichera

3. 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 STET V1.4.0.47 / Part I / section 3.4.3.2 / page 22

➤ 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 90 jours (AISP) 

• L'identifiant du terminal accédant (TermId) doit être obligatoirement fourni, sinon l’accès aux pages d’identification/authentification sera bloqué

• Seules les fonctionnalités DSP2 présentes sur la banque en ligne (référence: banque à distance sur internet fixe - pas la banque sur mobile) 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
  • OTP SMS
  • Clé physique (pour les entreprises)