MyBankMatch

Forbered forbindelsen

1. Sørg for at have en aktiv licens med produktet MY_BANK_MATCH og ledig kvote.
2. Åbn Kunder · MyBankMatch med din autentificerede session og den tilsvarende licens.
3. Klik på Connect bank, og gennemfør autentificeringen i det vindue, som Wealthreader hoster. Den tokeniserede forbindelse knyttes til din api_key; banktokenet sendes ikke til browseren og er ikke en forespørgselsparameter.
4. Opdater status i Kunder. Hvis banken kræver, at du autentificerer dig igen, skal du bruge Reconnect. Panelet tilbyder også en eksplicit test af IBAN/navn og de seneste maskerede forespørgsler.

Udstederen bruger et signeret engangslink og en fortsættelse, der er bundet til browseren. Hvis linket er udløbet, eller fortsættelsen går tabt, skal du anmode om et nyt fra Kunder.

Send en forespørgsel fra backend

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

Der sendes ikke JSON, og X-API-Key bruges ikke: nøglen er en del af den formularkodede body, ligesom 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 pladsholder, ikke en brugbar nøgle. IBAN og navn illustrerer anmodningen fra accepttesten; det er ikke kontrolleret her, at de giver en bestemt afgørelse. Forespørgslen kan blive faktureret: start den ikke som en automatisk opdatering af brugerfladen.

MyBankMatch returnerer bankens afgørelse. Den erstatter ikke dette svar med en lokal beregning af navnelighed. Den opretter, godkender eller udfører heller ikke en betalingsordre.

Fortolk svaret

HTTP 200 betyder, at der er opnået et resultat fra produktet, ikke nødvendigvis at navnet matcher. Kontrollér success og derefter payload.result.

Illustrativt eksempel på et delvist match (navn og SESSION er simulerede):

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

statistics.SESSION identificerer denne forespørgsel til fejlfinding, og execution_time angives i sekunder. Et vellykket svar indeholder ikke et error-objekt og returnerer ikke bankforbindelsens token.

Ved et delvist match skal du vise det indtastede navn og suggested_name hver for sig; erstat ikke stiltiende det første. Hvis du viser dem i HTML, skal de escapes som tekst.

Opsætnings-URL'en for NOT_CONFIGURED og REAUTH_REQUIRED er:

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

En genautentificering kan for eksempel returnere denne payload:

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

reason_code skal være et heltal mellem 2000 og 2999; for eksempel svarer 2000 til en fejl i loginoplysningerne. Tilslut igen fra Kunder i stedet for at gentage verifikationen i det uendelige.

NOT_POSSIBLE kan skyldes midlertidig utilgængelighed, et ugyldigt svar fra banken, manglende brugbar betaler-IBAN eller en adapter, der ikke er tilgængelig. Gem reason til fejlfinding, men tolk ikke disse tilfælde som en bekræftelse af ejerskab eller som et negativt match.

Validering, kvote og fejl

Validerings- og licensfejl følger den sædvanlige struktur: success: false, payload, error.code, error.message og statistics med SESSION, varighed og advarsler. Kontrollerede valideringer svarer med HTTP 400; meddelelsen kan indeholde diagnostiske oplysninger og må ikke bruges som en stabil identifikator.

Inputfejl og ikke-entydige resultater forbruger ikke kvoten af fakturerbare forespørgsler. Kvoten forbruges, når banken returnerer MATCH, PARTIAL_MATCH eller NO_MATCH; hvis et andet samtidigt kald opbruger den, returneres grænsefejlen i stedet for at bekræfte resultatet som gyldigt.

Prisen på 0,10 EUR gælder kun for kontraktens tre entydige resultater. Fakturering pr. forespørgsel og udelukkelsen af verificerede tilknytningssessioner er implementeret, men kræver det forudgående skema og en operatørs aktivering/gennemgang af faktureringsforespørgslerne; denne side dokumenterer ikke, at det er udrullet. Kun en verificeret tilknytning på serveren gør det muligt at udelukke en session fra standardberegningen af loginoplysninger/produkter: et operation_id fra browseren er ikke nok. Udløbne, ikke-auditerede eller historiske forsøg uden denne oprindelse er ikke automatisk undtaget, og der garanteres ingen andre gratis tællereffekter.

Begrænsninger i denne version

• Verifikationen bruger kundens egen tokeniserede forbindelse til Santander privatkunder. Den faktiske bankkompatibilitet er endnu ikke valideret, og kommerciel tilgængelighed garanteres ikke, blot fordi denne side er offentliggjort.
• Det hostede flow understøtter loginoplysninger og OTP/push-udfordringer, valg af metode og begrænset raster-QR. Udfordringer via script, OAuth, CAPTCHA eller flere aftaler er ikke implementeret og giver en sikker fejl; du kan anmode om et nyt link fra Kunder.
• Panelet kræver en autentificeret session. At indlæse status, vende tilbage fra bankens vindue og opdatere historikken sender ikke verifikationer til banken: kun en eksplicit indsendelse af formularen udfører en forespørgsel, der kan blive faktureret.
• Opbevar api_key på din server, og log ikke loginoplysninger, banktokens eller fulde navne i unødvendige integrationslogfiler. Brug SESSION over for support, og respekter forskellen mellem afgørelse, fejl og konfigurationsstatus.