A leggyakoribb integrációs hiba a Verification of Payee-nél, hogy egy NO_MATCH eredményt sikertelen kérésként kezelnek. Pedig nem az. Egy sikeres ellenőrzés, amely éppen azt mondja, hogy ez a név nem ehhez az IBAN-hoz tartozik, továbbra is egy 200-as válasz hasznos adatokkal. Ha összekeveri a kettőt, vagy elnyeli a csalásjelzéseket, vagy ijesztő hibákat mutat a felhasználóknak.
A négy séma-kód
Minden Verification of Payee válasz a négy szabványosított SEPA séma-kód egyikére képeződik le. A kódra ágaztasson, ne a szabad szövegre:
- MTCH - MATCH: a név megegyezik a számlatulajdonossal. Haladjon tovább.
- CMTC - CLOSE_MATCH: majdnem pontos (hiányzó középső név, kereskedelmi vs jogi név). Mutassa meg a javasolt ellenőrzött nevet, és kérje a fizető megerősítését.
- NMTC - NO_MATCH: a név nem ehhez az IBAN-hoz tartozik. Figyelmeztessen egyértelműen, és tiltsa le az automatikus jóváhagyást.
- NOAP - NOT_APPLICABLE: az ellenőrzést nem sikerült elvégezni (pl. a válaszoló bank nem elérhető). Hagyja, hogy a felhasználó fokozott óvatossággal döntsön.
Eredmény vs hiba
Ha a HTTP-státusz 200, akkor ellenőrzési eredménye van - olvassa a scheme_code mezőt. Ha 4xx/5xx, akkor hibája van - olvassa a hibakódot. Soha ne képezze le a NO_MATCH-et a hibaútvonalra.
A CLOSE_MATCH helyes kezelése
A CLOSE_MATCH az, ahol a jó UX nyer vagy veszít. A válasz tartalmazhatja az ellenőrzött számlatulajdonos nevét; jelenítse meg javaslatként (Erre gondolt...?), hogy a fizető megerősítsen vagy korrigáljon, ahelyett hogy feladná a fizetést. A CMTC kemény hibaként való kezelése frusztrálja a jogszerű felhasználókat.
Valódi hibakódok
A sémaeredményektől elkülönítve az átviteli szintű problémák szabványos HTTP-hibákat adnak vissza - például invalid_iban (400), unauthorized (401), rate_limited (429) és scheme_unavailable (503). Mindegyik tartalmaz egy kérés-azonosítót, hogy a támogatás nyomon követhesse. Minden híváshoz adjon meg egy stabil külső azonosítót, hogy az újrapróbálkozások idempotensek maradjanak, és a naplók összevethetők legyenek.