De meest voorkomende integratiefout bij de Verification of Payee is een NO_MATCH behandelen als een mislukt verzoek. Dat is het niet. Een geslaagde verificatie die zegt 'deze naam hoort niet bij deze IBAN' is nog steeds een 200-respons met nuttige data. Verwart u de twee, dan slikt u ofwel fraudesignalen in ofwel toont u gebruikers angstaanjagende fouten.
De vier schemacodes
Elk Verification of Payee-antwoord komt overeen met een van de vier gestandaardiseerde SEPA-schemacodes. Vertak op de code, niet op vrije tekst:
- MTCH - MATCH: de naam komt overeen met de rekeninghouder. Ga verder.
- CMTC - CLOSE_MATCH: bijna goed (ontbrekende tweede voornaam, handelsnaam vs. juridische naam). Toon de voorgestelde geverifieerde naam en vraag de betaler om bevestiging.
- NMTC - NO_MATCH: de naam hoort niet bij de IBAN. Waarschuw duidelijk en blokkeer automatische goedkeuring.
- NOAP - NOT_APPLICABLE: de controle kon niet worden afgerond (bijv. responderende bank onbereikbaar). Laat de gebruiker met extra voorzichtigheid beslissen.
Resultaat vs. fout
Is de HTTP-status 200, dan hebt u een verificatieresultaat - lees scheme_code. Is het 4xx/5xx, dan hebt u een fout - lees de foutcode. Map NO_MATCH nooit op uw foutpad.
CLOSE_MATCH goed afhandelen
Bij CLOSE_MATCH wordt goede UX gewonnen of verloren. Het antwoord kan de geverifieerde rekeninghoudernaam dragen; toon die als suggestie ('Bedoelde u…?') zodat de betaler bevestigt of corrigeert in plaats van de betaling af te breken. CMTC als harde mislukking behandelen frustreert legitieme gebruikers.
Echte foutcodes
Los van de schema-uitkomsten geven problemen op transportniveau standaard HTTP-fouten terug - bijvoorbeeld invalid_iban (400), unauthorized (401), rate_limited (429) en scheme_unavailable (503). Elk draagt een request id mee, zodat support het kan traceren. Geef bij elke aanroep een stabiele external id mee, zodat herhalingen idempotent blijven en logs aansluiten.