De meest voorkomende integratiefout met 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-antwoord met nuttige data. Verwar de twee en u slikt fraudesignalen in of toont 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 door.
- CMTC — CLOSE_MATCH: bijna goed (ontbrekende tweede voornaam, handelsnaam vs. juridische naam). Toon de voorgestelde geverifieerde naam en vraag de betaler te bevestigen.
- NMTC — NO_MATCH: de naam hoort niet bij de IBAN. Waarschuw duidelijk en blokkeer automatische goedkeuring.
- NOAP — NOT_APPLICABLE: de controle kon niet worden voltooid (bijv. ontvangende 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 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 zodat support het kan traceren. Geef bij elke aanroep een stabiele external id mee zodat retries idempotent blijven en logs verzoenen.