Het is verleidelijk om de Verification of Payee te integreren, een overeenkomst terug te zien komen en het als klaar te beschouwen. Maar de waarde van de VoP zit in de momenten waarop het antwoord geen schone overeenkomst is — en dat zijn precies de gevallen die een snelle test overslaat. Een serieus sandboxplan dekt ze allemaal.
Test elke uitkomst
Een sandbox zou u in staat moeten stellen elke schema-uitkomst op verzoek te reproduceren, meestal door specifieke testnamen of IBANs te sturen. Zorg ervoor dat uw UI en uw code voor elk het juiste doen.
- Overeenkomst (MTCH) — bevestig dat de betaling schoon kan doorgaan.
- Gedeeltelijke overeenkomst (CMTC) — bevestig dat u de voorgestelde geverifieerde naam toont om te bevestigen of corrigeren.
- Geen overeenkomst (NMTC) — bevestig dat u een duidelijke waarschuwing toont en niet automatisch doorgaat.
- Niet van toepassing (NOAP) — bevestig dat u 'kon niet verifiëren' sierlijk afhandelt, niet als een fout.
Vergeet de foutpaden niet
Naast de vier uitkomsten test wat er gebeurt met een misvormde IBAN, een ontbrekende begunstigdenaam, een verlopen credential en een timeout. Hier breken fragiele integraties in productie.
Houd tests deterministisch
Gebruik een sandbox met gedocumenteerde, deterministische testdata zodat een bepaalde invoer altijd dezelfde uitkomst teruggeeft. Dat maakt uw integratietests herhaalbaar in CI en betekent dat een fout op een echte regressie wijst, niet op een instabiele responder.
Van sandbox naar productie
Zodra elke uitkomst en elk foutpad zich correct gedraagt, is go-live meestal alleen het omschakelen van de basis-URL en de credentials. RoxPay biedt een sandbox met testcases voor elke uitkomst, zodat u de volledige stroom kunt valideren voordat u naar productie wijst.