BoursoBank a récemment informé nos équipes techniques de changements à venir dans la façon dont nous pouvons effectuer du Web Scraping, pour la synchronisation des comptes d’épargne et des crédits.
Aujourd’hui, le Web Scraping nécessite la saisie par l’utilisateur de ses identifiants BoursoBank au sein des widgets Linxo Connect. Dans la solution cible, les utilisateurs devront suivre un parcours d’authentification du même type que le parcours d’authentification de l’API DSP2 au travers d’une redirection vers des écrans de la banque. Comme pour l’API DSP2, ce parcours nous permettra de récupérer des tokens, qui nous permettront de faire du Web Scraping sans saisie des identifiants, et ainsi de continuer à récupérer les détails des comptes d’épargne et des crédits.
Le mode d’authentification du canal permettant de récupérer comptes d’épargne et crédits va donc évoluer d’un mode dit EMBEDDED (saisie des identifiants par l’utilisateur au sein des widgets Linxo Connect) vers un mode REDIRECT (redirection vers la banque pour que l’utilisateur s’authentifie et consente).
Nous considérons ce changement de fonctionnement comme positif : l’utilisateur s’authentifie auprès de BoursoBank et n’a plus par exemple à mettre à jour ses identifiants en cas de changement de code secret. Ce changement va par contre se refléter dans la configuration de notre connecteur BoursoBank. Ainsi, le connecteur (”provider” dans l’API) BoursoBank ne contiendra plus un canal REDIRECT et un canal EMBEDDED, mais 2 canaux REDIRECT. Les types de comptes associés à chaque canal ne changeront pas.
Bien que ce changement ne représente pas un changement de contrat d’API, nous pensons qu’il peut avoir des impacts dans certaines intégrations et préférons ainsi vous prévenir.
Parcours utilisateurs
Lors d’un parcours widgets nominal, un utilisateur ayant des comptes de paiement et des comptes d’épargne ou des crédits devra enchaîner deux parcours REDIRECT successifs. Il sera donc dirigé deux fois vers le portail de la banque pour s’authentifier à deux reprises. L’option d’effectuer un parcours unique donnant accès aux deux canaux a été écartée par BoursoBank.
A noter que la synchronisation du nouveau channel REDIRECT est soumise à la validité du token : comme pour le canal API DSP2, il sera nécessaire aux utilisateurs de se ré-authentifier tous les 180 jours afin de renouveler ce dernier.
Changements sur le provider BoursoBank
Comme évoqué plus haut, le provider BoursoBank, tel que retourné par le endpoint GET /providers aura deux “channel definitions” REDIRECT.
Afin de faciliter la distinction de ces deux canaux REDIRECT, nous allons introduire un nouveau champ 'access_type' (enum) dont les valeurs possibles sont : OPEN_BANKING (pour le canal permettant la récupération des comptes de paiement via l’API DSP2) ou OTHER (pour le canal permettant la récupération des comptes d’épargne et des crédits via Web Scraping). Ce champ sera obligatoire et donc présent sur tous les canaux retournés par notre API.
Voici un exemple de ce qui sera retourné par notre API :
{
...
"channel_definitions": [
{
...
"channel_definition_id": "8301",
"mode": "REDIRECT",
"access_type": "OPEN_BANKING",
"account_types": [ "CHECKINGS", "CREDIT_CARD" ],
...
},
{
...
"channel_definition_id": "8300",
"mode": "REDIRECT",
"access_type": "OTHER",
"account_types": [ "CHECKINGS", "CREDIT_CARD", "SAVINGS", "LOAN" ],
...
},
]
...
}
A noter que :
- le premier facteur différenciant reste le champ account_types
- si 2 channel_definitions ont des account_types en commun, alors le champ access_type peut être utilisé pour les différencier
- le nouveau canal REDIRECT pourra avoir les mêmes statuts qu’un canal REDIRECT classique (notamment TOKEN_EXPIRED après 180 jours)
Changements sur le Widget ‘edit_credentials’
Actuellement, le paramètre 'channel_definition_id' du endpoint 'edit_credentials' est marqué comme déprécié.
Cependant, avec les changements à venir apportés par BoursoBank, nous pensons qu’il peut être plus facile pour un intégrateur d’utiliser ce champ plutôt que le champ 'expected_account_types'. Nous pensons en effet que certains intégrateurs ont pu relier la valeur du paramètre 'expected_account_types' (PAYMENT ou OTHER) au mode d’authentification (REDIRECT ou EMBEDDED). Hors avec deux canaux REDIRECT, une telle correspondance ne fonctionnerait plus. Utiliser le paramètre 'channel_definition_id' au lieu du paramètre 'expected_account_types' peut être un moyen simple de pallier au problème.
Nous allons ainsi pérenniser le champ 'channel_definition_id' tout en conservant le champ 'expected_account_types'. Il sera alors possible pour les intégrateurs d’utiliser l’un ou l’autre de ces deux champs. Par conséquent, le paramètre 'expected_account_types' du edit_credentials de l'API n'est plus obligatoire.
Nos équipes travaillent actuellement sur ces changements. Nous sommes également en contact avec BoursoBank. Nous reviendrons prochainement vers vous pour vous communiquer le calendrier exact du déploiement de ces changements.
Dans cette attente, nos équipes restent disponibles pour toute question ou complément d’information.