MyBankMatch

Forberede tilkoblingen

1. Sørg for å ha en aktiv lisens med produktet MY_BANK_MATCH og tilgjengelig kvote.
2. Åpne Kunder · MyBankMatch med en autentisert økt og den tilhørende lisensen.
3. Klikk på Connect bank og fullfør autentiseringen i vinduet som driftes av Wealthreader. Den tokeniserte tilkoblingen knyttes til din api_key; banktokenet leveres ikke til nettleseren og er ikke en spørreparameter.
4. Oppdater statusen under Kunder. Hvis banken krever ny autentisering, bruker du Reconnect. Panelet tilbyr også en eksplisitt test av IBAN/navn og de siste maskerte forespørslene.

Utstederen bruker en signert engangslenke og en fortsettelse som er bundet til nettleseren. Hvis lenken har utløpt eller fortsettelsen går tapt, ber du om en ny under Kunder.

Sende en forespørsel fra backend

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

Det sendes ikke JSON, og X-API-Key brukes ikke: nøkkelen er en del av den skjemakodede kroppen, på samme måte som i /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> er en plassholder, ikke en brukbar nøkkel. IBAN-et og navnet illustrerer akseptforespørselen; det er ikke kontrollert her at de gir et bestemt resultat. Forespørselen kan være fakturerbar: ikke send den som en automatisk oppdatering av grensesnittet.

MyBankMatch returnerer bankens vurdering. Tjenesten erstatter ikke dette svaret med en lokal beregning av navnelikhet. Den oppretter, autoriserer eller utfører heller ikke en betalingsordre.

Tolke svaret

HTTP 200 betyr at produktet har gitt et resultat, ikke at navnet nødvendigvis stemmer. Kontroller success og deretter payload.result.

Illustrerende eksempel på delvis samsvar (simulert navn og SESSION):

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

statistics.SESSION identifiserer denne forespørselen for feilsøking, og execution_time er oppgitt i sekunder. Et vellykket svar inneholder ikke et error-objekt og returnerer ikke tokenet for banktilkoblingen.

Ved delvis samsvar viser du det innskrevne navnet og suggested_name hver for seg; ikke erstatt det første i det stille. Hvis du viser dem i HTML, må de escapes som tekst.

Klargjørings-URL-en for NOT_CONFIGURED og REAUTH_REQUIRED er:

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

En ny autentisering kan for eksempel returnere denne payload:

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

reason_code må være et heltall mellom 2000 og 2999; for eksempel tilsvarer 2000 en feil med påloggingsinformasjonen. Koble til på nytt under Kunder i stedet for å gjenta verifiseringen i det uendelige.

NOT_POSSIBLE kan skyldes midlertidig utilgjengelighet, et ugyldig svar fra banken, mangel på et brukbart betaler-IBAN eller en utilgjengelig adapter. Ta vare på reason for feilsøking, men ikke gjør disse tilfellene om til en bekreftelse av eierskap eller et negativt samsvar.

Validering, kvote og feil

Validerings- og lisensfeil følger den vanlige svarstrukturen: success: false, payload, error.code, error.message og statistics med SESSION, varighet og advarsler. Kontrollerte valideringer svarer med HTTP 400; meldingen kan inneholde feilsøkingsinformasjon og skal ikke brukes som en stabil identifikator.

Inndatafeil og ikke-konklusive resultater forbruker ikke kvoten for fakturerbare forespørsler. Kvoten forbrukes når banken returnerer MATCH, PARTIAL_MATCH eller NO_MATCH; hvis et annet kall bruker den opp samtidig, returneres grensefeilen i stedet for at resultatet bekreftes som vellykket.

Prisen på 0,10 EUR gjelder bare de tre konklusive resultatene i kontrakten. Fakturering per forespørsel og unntak for verifiserte tilknytningsøkter er implementert, men krever det forutgående skjemaet og at en operatør aktiverer/gjennomgår faktureringsspørringene; denne siden dokumenterer ikke at dette er utrullet. Bare en verifisert tilknytning på serversiden gjør det mulig å utelate en økt fra standardberegningen av påloggingsinformasjon/produkter: en operation_id fra nettleseren er ikke nok. Utløpte, ikke-reviderte eller historiske forsøk uten slik opprinnelse får ikke automatisk unntak, og andre gratis telleffekter garanteres heller ikke.

Begrensninger i denne versjonen

• Verifiseringen bruker kundens egen tokeniserte tilkobling til Santander privatkunder. Den faktiske bankkompatibiliteten er ennå ikke validert, og publiseringen av denne siden garanterer ikke kommersiell tilgjengelighet.
• Den driftede flyten støtter påloggingsinformasjon og OTP/push-utfordringer, valg av metode og begrenset raster-QR. Utfordringer via skript, OAuth, CAPTCHA eller flere kontrakter er ikke implementert og gir en sikker feil; du kan be om en ny lenke under Kunder.
• Panelet krever en autentisert økt. Å laste inn statusen, gå tilbake fra bankvinduet og oppdatere historikken sender ikke verifiseringer til banken: bare en eksplisitt innsending av skjemaet utfører en potensielt fakturerbar forespørsel.
• Hold api_key på serveren din, og ikke logg påloggingsinformasjon, banktokener eller fulle navn i unødvendige integrasjonslogger. Bruk SESSION for support og respekter skillet mellom vurdering, feil og konfigurasjonsstatus.