Initier un paiement

Cas d’utilisation de l’API d’initiation de paiement :

• Le PISP fait une demande de paiement pour le compte d’un commerçant : Le 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. L’e-commerçant transmet les caractéristiques du paiement demandé au PISP et redirige le PSU vers le portail du PISP.
  
  Le PISP prépare la demande de paiement et l’envoie à l’établissement teneur de compte.
  
  L’IBAN bénéficiaire de l’e-commerçant, le montant et la date de la transaction sont indiqués dans la demande d’initiation de paiement.
   
• Le PISP fait une demande de virement pour le compte du titulaire du compte. Le PSU fournit au PISP les informations nécessaires au transfert.
  
  Le PISP prépare la demande de virement et l’envoie à l’établissement qui détient le compte du PSU.
  
  La méthode d’authentification supportée par l’établissement et le mode REDIRECT.
  
  Le PISP fournit lors de sa demande d’initiation un ou deux URL callback. La première sera appelée par l’établissement 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 en cas de refus du consentement . Cette deuxième URL est facultative.

Image

Obtenir les données de l’initiation de paiement (PISP)

Cet appel permet au PISP de récupérer l’ensemble des données de l’initiation de paiement enrichies des identifiants ressources et des statuts de l’initiation et du paiement qu’elle contient.

Les données sont accessibles pendant 35 jours.

Annuler une initiation de paiement (PISP)

Cet appel permet  au PISP d’annuler une initiation de paiement  tant que le paiement n’est pas considéré comme exécuté par la banque.

Confirmer une initiation de paiement (PISP)

Service non disponible en mode redirect (recueil du consentement).

Publications réglementaires

Comment récupérer son jeton d'accès OAuth2 ?

1. Vous envoyez directement une requête vers l’infrastructure informatique d’autorisation de la banque teneuse de compte, le détail des liens et des paramètres se trouvent ci-après :
    

Image

2. La banque teneuse de compte (ASPSP) va effectuer des vérifications liées à votre profil en tant que TPP (validité des certificats et de votre rôle dans le référentiel de place, non révocation de votre profil, etc…).

    

3. Une fois ces vérifications effectuées et si elles sont concluantes, la banque va vous répondre via un code HTTP 200 (OK) et les données suivantes :

Image

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 400 et des données indiquant « Token invalide ». 

Cette requête pourra être renvoyée une fois un nouveau jeton d’accès de type Client Credential demandé et obtenu. 

A noter que la durée de vie maximale d’un jeton d’accès est de 180 jours calendaires.

4 requêtes du prestataire de service initiateur de paiements

Le Prestataire de service de paiement possédant le rôle de PISP peut effectuer 4 requêtes auprès de la banque teneur de compte (ASPSP) du client débité (PAO).

POST /payment-requests

Cette méthode permet d’envoyer à l’ASPSP toutes les informations nécessaires pour effectuer un paiement. Le paiement peut avoir été demandé par le bénéficiaire (par exemple, le marchand ou PSU) ou par le titulaire du compte lui-même (le PAO).

GET /payment-requests

Cette méthode permet d’obtenir les données de l’initiation de paiement enrichies du statut de l’initiation et du paiement.

PUT /payment-requests

Cette méthode permet d’envoyer à l’ASPSP une demande de modification d’une demande d’initiation de paiement déjà enregistrée, à condition que le paiement n’ait pas encore été exécutée. Cette méthode n’étant pas encore disponible, l’appel à cette requête renverra un code HTTP 405.

POST /confirmation

Cette méthode, liée au mode d’authentification, permet de confirmer la demande de paiement ou d’annulation de la demande de paiement à l’ASPSP en transmettant un facteur d’authentification du titulaire du compte débité afin que l’ASPSP puisse poursuivre la demande. Cette méthode n’étant pas encore disponible, l’appel à cette requête renverra un code HTTP 405.

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 portail developer 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 :

Image

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

Image

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)

Initier un paiement

Principe

Envoyer une demande d’initiation de paiement unique en €.

Contexte

Cet appel permet d’envoyer à la banque teneur de compte (ASPSP) d’un client d’une banque (PAO) une demande d’initiation de paiement venant débiter le compte du PAO pour créditer le compte de l’usager du service de paiement (PSU) pour lequel le Prestataire de service de paiement (PISP) est connecté.

Dans un premier temps, seule l’initiation de paiement unique 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 (HTTP 201) vous sera retournée.

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 section « Eligibilité »), et d’avoir récupéré le jeton d’accès OAuth2.

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 section « Limitations », cf. extrait ci-dessous :

Nous avons par exemple :

• POST https://www.<codetab>.oba-bad-me-live.api.89c3.com/stet/psd2/v1.6.2/payment-requests (nouvelle url à prendre en compte dès à présent)
  (Pour rappel, l’url 89C3 existante www.<codetab>.live.api.89C3.com ne sera plus disponible à partir du 28/09/2025)

Paramètres obligatoires ou facultatifs du body

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 currency doit être renseignée à EUR (pas de virements en devises)
   
• La donnée requestedExecutionDate doit être égale ou supérieure à la date du jour
   
• La requête doit contenir une demande d’initiation pour un seul paiement
   
• La donnée numberOfTransactions doit être valorisée à « 1 »
   
• La donnée executionRule doit être valorisée à « FWNG–following » (exécution le premier jour ouvré suivant) pour préciser les corrections de date d’exécution des paiements, si la date de traitement tombe un week-end ou un jour fermé pour la banque
   
• La donnée frequency ne doit pas être alimentée, les virements récurrents n’étant pas autorisés
   
• La donnée localInstrument ne doit pas être valorisée, seuls les SCT étant acceptés pour le moment
   
• Seuls les IBAN sont supportés pour les données Iban, debtorAccount et creditorAccount
   
• La donnée successfullReportUrl est obligatoire pour le mode d’authentification REDIRECT mis en œuvre
   
• 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’AF ne seront pas possibles en 2020
   
• 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
  • Exemples :
    • 2019-11-12T00:00:00.000+02:00
    • 2019-11-12T00:00:00.000+0200
    • 2019-11-12T00:00:00.000

Codes erreur

Exemple

Requête : POST /stet/psd2/v1.6.2/payment-requests

Body :
{ « creationDateTime »: « 2019-03-13T12:56:11.122Z », »numberOfTransactions »: 1, « paymentInformationId »: « 123456789ABCD », « paymentTypeInformation »: { « categoryPurpose »: « CASH », « instructionPriority »: « HIGH », « serviceLevel »: « SEPA », « localInstrument »: « INST » }, « purpose »: « ACCT », « beneficiary » : { « creditor »: { « name »: « John Doe », « postalAddress »: { « addressLine »: [ « 10 rue de la Rue », »75001 Paris » ], « country »: « FR » }, « privateId »: { « identification »: « 12345678900 », « issuer »: « FR », « schemeName »: « SREN » } }, « creditorAccount »: { « iban »: « FR7613825002000800000123456 »

},

« creditorAgent »: { « bicFi »: « CEPAFRPP670 » }, « id »: « string », « isTrusted »: false }, « debtor »: { « name »: « Janette Rees », « postalAddress »: { « addressLine »: [ « 12 rue de la DSP2″, »75006 Paris » ], « country »: « FR » }, « privateId »: { « identification »: « 1447114700 », « issuer »: « FR », « schemeName »: « COID » } }, « debtorAccount »: { « iban »: « FR353000799999A40166510BB25 » }, « debtorAgent »: { « bicFi »: « NATXFRPPXXX » }, « initiatingParty »: { « name »: « Small Heath », « organisationId »: { « identification »: « 00987654321 », « issuer »: « FR », « schemeName »: « BANK » }, « postalAddress »: { « addressLine »: [ « 92 rue de la Banque », »75000 Paris » ], « country »: « FR » } }, « booking »: false, « chargeBearer »: « SLEV », « requestedExecutionDate »: « 2023-03-13T12:56:11.122Z », « creditTransferTransaction »: [ { « instructedAmount »: { « amount »: « 100 », « currency »: « EUR » }, « paymentId »: { « endToEndId »: « 987654321DCBA », « instructionId »: « DCBA987654321 » }, « regulatoryReportingCodes »: [ « string » ], « remittanceInformation »: [ « Life always finds a way » ] } ], « supplementaryData »: { « acceptedAuthenticationApproach »: [ « REDIRECT » ], « appliedAuthenticationApproach »: « REDIRECT », « scaHint »: « noScaExemption », « successfulReportUrl »: « https://www.successful.fr« , « unsuccessfulReportUrl »: « https://www.unsuccessful.fr » }}

Résultat : Status code HTTP 201

{ « appliedAuthenticationApproach »: « REDIRECT », « _links »: { « consentApproval »: { « href »: « TPPPISPurlConsentApproval/psuId.html?resourceId=0000000180-1551358254000131359238543&nonce=Id-2ed9775ce61639e9a3c94ecc », « templated »: null } }}

Assemblage Sandbox

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

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

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

• Le premier pour récupérer le jeton d’autorisation (voir la rubrique « Documentation » > « Comment récupérer son jeton d'accès OAuth2 ? » ) ;
   
• Le second pour faire l’appel à l’API DSP2 « Initiation de paiement » (voir les cas d’usage « Initier un paiement », « Récupérer le statut », « Confirmer une initiation » et « Annuler une initiation »).

Prérequis

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

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

Le point d’entrée dépendra du code établissement <cdetab> :

Nous avons par exemple :

• POST  https://www.30021.oba-bad-me-live.api.89c3.com/stet/psd2/v1.6.2/payment-requests pour initier un paiement pour un client de Natixis CIB en sanbdox
  (nouvelle url à prendre en compte dès à présent)
  (Pour rappel, l’url 89C3 existante www.<codetab>.live.api.89C3.com ne sera plus disponible à partir du 28/09/2025)

Limitations

• Le cas « 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).
   
• 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.

Données de tests

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

• Les clients fictifs proposés par NATIXIS Global Trade sont des clients corporates
   
• Les caractéristiques de leurs comptes y sont déclinées (mono-compte, multi-comptes, solde du compte)
   
• Les données utiles attendues en entrée par les API y sont énumérées (identifiant Portail Natixis Global Trade, IBAN)

Gérer les erreurs

Voici la liste de descriptions des codes erreurs pour chaque méthode (dont ceux étant recensés dans la norme définie par le CFONB (Codification CFONB) :

• Obtenir la liste des comptes : GET /accounts
   
• Obtenir la liste des soldes : GET /accounts/{accountRessourceId}/balances
   
• Obtenir la liste des transactions : GET /accounts/{accountRessourceId}/transactions

Pour en savoir plus sur la norme définie par le CFONB : Codification CFONB

Politique de décommissionnement des versions de l’API

Image

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 Groupe BPCE API Store dans la partie « Roadmap » de l’API impactée. 

Une communication via courriel vers les correspondants des prestataires enrôlés sur le portail developer 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.

Limitations fonctionnelles

Les limitations de cette API DSP2 sont les suivantes :

• Applicable à tous les clients Natixis CIB avec l’abonnement en ligne permettant un accès au service d’initiation de paiement adhoc
• Ne s’applique qu’aux comptes paiement des clients (cf. texte de la Directive DSP2)
• Les demandes d’initiation de paiement sont limitées à un paiement SCT CORE (immediat ou différé, non instantané)
• Le bénéficiaire d’une demande d’initiation de paiement doit être référencé dans la liste des bénéficiaires du client Natixis GTB
• Les ordres permanents et récurrents ne sont pas acceptés
• Les demandes de paiement au-delà des 30 jours ne sont pas acceptées
• N’utilise que le mode d’authentification par redirection (Authentification Forte du client demandée et gérée via la banque)
• Le champ chargeBearer est obligatoire pour la méthode POST /payment-requests (ainsi que pour les suivantes) et doit être valorisé à « SLEV »
• Le champ categoryPurpose est obligatoire pour la méthode POST /payment-requests (ainsi que pour les suivantes)
• Le champ creditorAccount est obligatoire pour la méthode POST /payment-requests (ainsi que pour les suivantes)
• Le champ successfulReportUrl est obligatoire pour la méthode POST /payment-requests (ainsi que pour les suivantes)

Une seule app consommatrice peut être déclarée à ce jour par le TPP (même OID = client_Id) sachant qu’il y a possibilité de gérer :

• les modèles de partenariat en marque blanche et en tiers-utilisateur
• plusieurs certificats par app consommatrice / client_Id TPP et plusieurs URL de redirection

Limitations techniques

[Nom des champs dans la norme STET]

Demande de paiement:

• Nombre de paiement [numberOfTransactions] « 1 »
• Frais pour virement international [chargeBearer]
• Date de paiement [requestedExecutionDate] max 30 jours au delà de la date du jour

Accès aux données de production

Le code établissement (voir ci-dessous) permettra d’adresser le bon backend via le point d’accès www.<cdetab>.oba-bad-me-live.api.89c3.com (nouvelle url à prendre en compte dès à présent)
(ou www.<cdetab>.live.api.natixis.fr aligné sur le nom de domaine de l’accès direct www.natixis.fr)
(Pour rappel, l’url 89C3 existante www.<codetab>.live.api.89C3.com ne sera plus disponible à partir du 28/09/2025)

Eligibilité

Les ressources de l’API « Initiation de paiement » 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:

• « PSD »
• 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 Enregistrement DSP2 des certificats de production signés par une autorité de certification agréée (AC) :

• un premier jeu de certificats QWAC (pour l’authentification mutuelle TLS) et QSEALC (à charger sur notre passerelle via l’API Enregistrement DSP2) pour la sandbox
• un autre jeu de certificats QWAC (pour l’authentification mutuelle TLS) et QSEALC (à charger sur notre passerelle via l’API Enregistrement DSP2) 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 éléments de la nouvelle AC sont bien chargés sur nos infrastructures.

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

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 89C3 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 :

Image

Versionning de l’API

Vous pouvez consulter la FAQ au sujet des textes de la norme STET.