MyBankMatch

Préparer la connexion

1. Disposez d’une licence active avec le produit MY_BANK_MATCH et d’un quota disponible.
2. Ouvrez Clients · MyBankMatch avec votre session authentifiée et la licence correspondante.
3. Cliquez sur Connect bank et terminez l’authentification dans la fenêtre hébergée par Wealthreader. La connexion tokenisée est associée à votre api_key ; le jeton bancaire n’est pas transmis au navigateur et n’est pas un paramètre de requête.
4. Actualisez l’état dans Clients. Si la banque exige une nouvelle authentification, utilisez Reconnect. Le panneau propose également un test explicite IBAN/nom et les dernières requêtes masquées.

L’émetteur utilise un lien signé à usage unique et une continuation liée au navigateur. Si le lien a expiré ou perd cette continuation, demandez-en un autre depuis Clients.

Envoyer une requête depuis le backend

POST https://api.wealthreader.com/my-bank-match/
Content-Type: application/x-www-form-urlencoded

Aucun JSON n’est envoyé et X-API-Key n’est pas utilisé : la clé fait partie du corps encodé en formulaire, comme pour /entities/.

curl --request POST 'https://api.wealthreader.com/my-bank-match/' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'api_key=<SU_API_KEY>' \
  --data-urlencode 'iban=ES9321005707250200257112' \
  --data-urlencode 'name=Wealthreader S.L.'

<SU_API_KEY> est un espace réservé, pas une clé utilisable. L’IBAN et le nom illustrent la requête d’acceptation ; il n’a pas été vérifié ici qu’ils produisent un verdict précis. La requête peut être facturable : ne la lancez pas comme une actualisation automatique de l’interface.

MyBankMatch renvoie le verdict de la banque. Il ne remplace pas cette réponse par un calcul local de similarité des noms. Il ne crée, n’autorise ni n’exécute pas non plus d’ordre de paiement.

Interpréter la réponse

HTTP 200 indique qu’un résultat du produit a été obtenu, pas que le nom corresponde nécessairement. Vérifiez success, puis payload.result.

Exemple illustratif de correspondance partielle (nom et SESSION simulés) :

{
  "success": true,
  "payload": {
    "result": "PARTIAL_MATCH",
    "suggested_name": "TITULAR DE EJEMPLO S.L."
  },
  "statistics": {
    "SESSION": "0000000000000000",
    "execution_time": 0.42,
    "warnings": []
  }
}

statistics.SESSION identifie cette requête pour le diagnostic et execution_time est exprimé en secondes. Une réponse correcte n’inclut pas d’objet error et ne renvoie pas le jeton de la connexion bancaire.

En cas de correspondance partielle, affichez séparément le nom saisi et suggested_name ; ne remplacez pas silencieusement le premier. Si vous les affichez en HTML, échappez-les comme du texte.

L’URL de configuration de NOT_CONFIGURED et REAUTH_REQUIRED est :

https://www.wealthreader.com/clients/#my-bank-match

Par exemple, une nouvelle authentification peut renvoyer ce payload :

{
  "result": "REAUTH_REQUIRED",
  "setup_url": "https://www.wealthreader.com/clients/#my-bank-match",
  "reason_code": 2000
}

reason_code doit être un entier compris entre 2000 et 2999 ; par exemple, 2000 correspond à un échec des identifiants. Reconnectez-vous depuis Clients au lieu de répéter indéfiniment la vérification.

NOT_POSSIBLE peut être dû à une indisponibilité temporaire, une réponse bancaire non valide, l’absence d’un IBAN payeur utilisable ou un adaptateur indisponible. Conservez reason pour le diagnostic, mais ne transformez pas ces cas en confirmation de titularité ni en correspondance négative.

Validation, quota et erreurs

Les erreurs de validation ou de licence suivent l’enveloppe habituelle : success: false, payload, error.code, error.message et statistics avec SESSION, la durée et les avertissements. Les validations contrôlées répondent HTTP 400 ; le message peut inclure des informations de diagnostic et ne doit pas être utilisé comme identifiant stable.

Les erreurs de saisie et les résultats non concluants ne consomment pas le quota de requêtes facturables. Le quota est consommé lorsque la banque renvoie MATCH, PARTIAL_MATCH ou NO_MATCH ; si un autre appel l’épuise simultanément, l’erreur de limite est renvoyée au lieu de confirmer le résultat comme correct.

Le prix de 0,10 EUR correspond uniquement aux trois résultats concluants du contrat. Le mode de facturation par requête et l’exclusion des sessions de liaison vérifiées sont implémentés, mais nécessitent le schéma préalable ainsi que l’activation/la révision des requêtes de facturation par un opérateur ; cette page n’atteste pas ce déploiement. Seule une association vérifiée côté serveur permet d’exclure une session du calcul standard des identifiants/produits : un operation_id du navigateur ne suffit pas. Les tentatives expirées, non auditées ou historiques sans cette provenance ne bénéficient d’aucune exemption automatique, et aucun autre effet de compteur gratuit n’est garanti.

Limites de cette version

• La vérification utilise la connexion tokenisée propre au client avec Santander particuliers. La compatibilité bancaire réelle n’a pas encore été validée et la publication de cette page ne garantit pas la disponibilité commerciale.
• Le flux hébergé prend en charge les identifiants et les défis OTP/push, la sélection de la méthode et un QR raster borné. Les défis par script, OAuth, CAPTCHA ou multicontrat ne sont pas implémentés et produisent une erreur sûre ; vous pouvez demander un nouveau lien depuis Clients.
• Le panneau nécessite une session authentifiée. Charger l’état, revenir de la fenêtre de la banque et actualiser l’historique n’envoient pas de vérifications à la banque : seul l’envoi explicite du formulaire effectue une requête potentiellement facturable.
• Conservez l’api_key sur votre serveur et n’enregistrez pas d’identifiants, de jetons bancaires ni de noms complets dans des journaux d’intégration inutiles. Utilisez SESSION pour le support et respectez la distinction entre verdict, erreur et état de configuration.