MyBankMatch

De koppeling voorbereiden

1. Zorg voor een actieve licentie met het product MY_BANK_MATCH en beschikbaar quotum.
2. Open Clients · MyBankMatch met je geauthenticeerde sessie en de bijbehorende licentie.
3. Klik op Connect bank en voltooi de authenticatie in het door Wealthreader gehoste venster. De getokeniseerde koppeling wordt aan je api_key gekoppeld; het banktoken wordt niet aan de browser geleverd en is geen queryparameter.
4. Vernieuw de status in Clients. Als de bank opnieuw authenticatie vereist, gebruik dan Reconnect. Het paneel biedt ook een expliciete IBAN/naam-test en de laatste gemaskeerde opvragingen.

De uitgever gebruikt een ondertekende eenmalige link en een aan de browser gebonden voortzetting. Als de link is verlopen of die voortzetting verliest, vraag dan een nieuwe aan in Clients.

Een opvraging vanuit de backend versturen

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

Er wordt geen JSON verzonden en X-API-Key wordt niet gebruikt: de sleutel maakt deel uit van de als formulier gecodeerde body, net als bij /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> is een tijdelijke aanduiding, geen bruikbare sleutel. De IBAN en de naam illustreren het acceptatieverzoek; hier is niet gecontroleerd dat ze een bepaald oordeel opleveren. De opvraging kan kosten met zich meebrengen: verstuur haar niet als automatische vernieuwing van de interface.

MyBankMatch geeft het oordeel van de bank terug. Het vervangt dat antwoord niet door een lokale berekening van naamovereenkomst. Het maakt ook geen betaalopdracht aan, autoriseert die niet en voert die niet uit.

Het antwoord interpreteren

HTTP 200 geeft aan dat er een resultaat van het product is verkregen, niet dat de naam noodzakelijkerwijs overeenkomt. Controleer success en daarna payload.result.

Illustratief voorbeeld van een gedeeltelijke overeenkomst (naam en SESSION gesimuleerd):

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

statistics.SESSION identificeert deze opvraging voor diagnose en execution_time wordt uitgedrukt in seconden. Een correct antwoord bevat geen error-object en geeft het token van de bankkoppeling niet terug.

Toon bij een gedeeltelijke overeenkomst de ingevoerde naam en suggested_name apart; vervang de ingevoerde naam niet stilzwijgend. Als je ze in HTML weergeeft, escape ze dan als tekst.

De instellings-URL voor NOT_CONFIGURED en REAUTH_REQUIRED is:

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

Een herauthenticatie kan bijvoorbeeld deze payload teruggeven:

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

reason_code moet een geheel getal tussen 2000 en 2999 zijn; 2000 staat bijvoorbeeld voor een fout in de inloggegevens. Koppel opnieuw vanuit Clients in plaats van de verificatie eindeloos te herhalen.

NOT_POSSIBLE kan het gevolg zijn van tijdelijke onbeschikbaarheid, een ongeldig antwoord van de bank, het ontbreken van een bruikbare IBAN van de betaler of een niet-beschikbare adapter. Bewaar reason voor diagnose, maar maak van deze gevallen geen bevestiging van het rekeninghouderschap en geen negatieve overeenkomst.

Validatie, quotum en fouten

Validatie- of licentiefouten volgen de gebruikelijke envelop: success: false, payload, error.code, error.message en statistics met SESSION, duur en waarschuwingen. Gecontroleerde validaties antwoorden met HTTP 400; het bericht kan diagnostische informatie bevatten en mag niet als stabiele identificatie worden gebruikt.

Invoerfouten en niet-sluitende resultaten verbruiken geen quotum voor factureerbare opvragingen. Het quotum wordt verbruikt wanneer de bank MATCH, PARTIAL_MATCH of NO_MATCH teruggeeft; als een andere aanroep het gelijktijdig opgebruikt, wordt de limietfout teruggegeven in plaats van het resultaat als correct te bevestigen.

De prijs van 0,10 EUR geldt uitsluitend voor de drie sluitende resultaten van het contract. Facturering per opvraging en de uitsluiting van geverifieerde koppelingssessies zijn geïmplementeerd, maar vereisen het voorafgaande schema en de activering/controle van de factureringsquery's door een operator; deze pagina toont die uitrol niet aan. Alleen een geverifieerde koppeling aan de serverzijde maakt het mogelijk een sessie uit te sluiten van de standaardberekening van inloggegevens/producten: een operation_id uit de browser is niet voldoende. Verlopen, niet-geauditeerde of historische pogingen zonder die herkomst krijgen geen automatische vrijstelling, en er worden geen andere gratis tellereffecten gegarandeerd.

Beperkingen van deze versie

• De verificatie gebruikt de eigen getokeniseerde koppeling van de klant met Santander particulieren. De werkelijke compatibiliteit met banken is nog niet gevalideerd en de publicatie van deze pagina garandeert geen commerciële beschikbaarheid.
• De gehoste flow ondersteunt inloggegevens en OTP-/pushuitdagingen, methodekeuze en begrensde raster-QR. Uitdagingen via script, OAuth, CAPTCHA of meerdere contracten zijn niet geïmplementeerd en leveren een veilige fout op; je kunt een nieuwe link aanvragen in Clients.
• Het paneel vereist een geauthenticeerde sessie. De status laden, terugkeren uit het bankvenster en de geschiedenis vernieuwen sturen geen verificaties naar de bank: alleen het expliciet verzenden van het formulier voert een mogelijk factureerbare opvraging uit.
• Bewaar de api_key op je server en leg geen inloggegevens, banktokens of volledige namen vast in onnodige integratielogs. Gebruik SESSION voor support en respecteer het onderscheid tussen oordeel, fout en configuratiestatus.