Verification of Payee API

Tak. Wywołanie weryfikacji zwraca odpowiedź synchronicznie, zwykle w czasie znacznie krótszym niż sekunda, i zawiera BIC banku odpowiadającego oraz czas przetwarzania przez PSP, dzięki czemu można monitorować wydajność.

Wywołania są uwierzytelniane za pomocą tokenu Bearer poprzez HTTPS. Można również skorzystać z panelu RoxBusiness do doraźnych weryfikacji bez pisania kodu.

Znormalizowany wynik (MATCH, CLOSE_MATCH, NO_MATCH, NOT_APPLICABLE), kod typu zgodności schematu SEPA, identyfikator weryfikacji, BIC odpowiadający, czas przetwarzania i opcjonalny zewnętrzny identyfikator.

Tak - wywołaj punkt końcowy dla każdego rekordu, aby zweryfikować cały plik dostawców lub odbiorców przed zwolnieniem paczki płatności. Rozwiązanie jest przygotowane na dużą przepustowość.

Tak. Punkt końcowy jest bezstanowy, więc możesz wywołać go przy tworzeniu odbiorcy - na przykład na etapie wdrożenia sprzedawcy lub dostawcy - a następnie ponownie bezpośrednio przed każdą wypłatą. Ponowna weryfikacja przy wypłacie wychwytuje dane bankowe zmienione po wdrożeniu, a właśnie tam najczęściej dochodzi do oszustwa polegającego na przekierowaniu faktury lub wypłaty.

Weryfikacja to jedno wywołanie REST na rekord, więc plik wypłat z tysiącami odbiorców obsługujesz partiami: przejdź przez plik, wywołaj punkt końcowy dla każdego rekordu i zbierz wyniki przed zwolnieniem paczki. Ponieważ API jest przygotowane na dużą przepustowość, tempo pętli dopasowujesz do własnego okna wypłat, zamiast być ograniczanym przez wdrożenie w każdym banku. Porozmawiaj z nami o swoich wolumenach, a wspólnie dobierzemy przepustowość.

Tak. Ta sama weryfikacja jest dostępna w panelu RoxBusiness, więc zespół finansowy lub operacyjny może sprawdzić pojedynczego odbiorcę - kontrola typu „know your payee” przed wysłaniem pieniędzy - podczas gdy programiści korzystają z API w zautomatyzowanych przepływach.

Tak. Weryfikacja porównuje przesłaną nazwę z zarejestrowanym posiadaczem rachunku, niezależnie od tego, czy jest to osoba fizyczna czy firma, i jest wykorzystywana w przepływie mandatów polecenie zapłaty SEPA RoxPay jako kontrola wstępna.

NO_MATCH nie jest błędem transportu - to prawidłowa odpowiedź 200 informująca, że nazwa nie należy do tego numeru IBAN. Traktuj to jako zdecydowany stop w swoim interfejsie lub paczce płatności: wyświetl jasne ostrzeżenie, zablokuj automatyczną akceptację i pozwól użytkownikowi ponownie zweryfikować odbiorcę przed wysłaniem.

CLOSE_MATCH (kod schematu CMTC) oznacza, że nazwa jest prawie prawidłowa - brakuje drugiego imienia, występuje nazwa prawna inna niż nazwa handlowa. Odpowiedź zawiera zweryfikowaną nazwę posiadacza rachunku, dzięki czemu można ją wyświetlić jako propozycję i poprosić płatnika o potwierdzenie, zamiast odrzucać płatność.

W przypadku osób prawnych schemat pozwala na weryfikację względem identyfikatora organizacji (np. włoskiego numeru Partita IVA / Codice Fiscale) oraz względem nazwy. Przesyłasz identyfikator w zapytaniu, a API zwraca standardowy wynik zgodności - przydatne, gdy nazwa zarejestrowana różni się od nazwy handlowej.

Tak. Przed zwolnieniem paczki płatności przejdź przez plik dostawców lub wynagrodzeń i wywołaj punkt końcowy weryfikacji dla każdego rekordu. Rozwiązanie jest przygotowane na dużą przepustowość, dzięki czemu zespoły finansowe mogą masowo walidować numery IBAN względem nazw przed każdym przelewem.

Tak. Wysyłasz zapytanie JSON z nazwą odbiorcy i numerem IBAN, a w odpowiedzi otrzymujesz wynik, zweryfikowaną nazwę (w przypadku częściowej zgodności) i BIC odpowiadający. Zobacz pełne zapytanie i odpowiedź w naszym przykładzie VoP, a struktury danych i kody schematu w dokumentacji API.

Potraktuj wywołanie weryfikacji jako jeden dodatkowy krok przed autoryzacją płatności. Uwierzytelnij się tokenem Bearer, wyślij metodą POST nazwę odbiorcy i numer IBAN, odczytaj wynik, a następnie rozgałęź logikę: kontynuuj przy MATCH, pokaż sugerowaną nazwę i poproś o potwierdzenie przy CLOSE_MATCH, zablokuj automatyczną akceptację przy NO_MATCH i pozwól płatnikowi zdecydować przy NOT_APPLICABLE. Ponieważ punkt końcowy jest bezstanowy, to samo wywołanie wpina się w finalizację zakupu, wdrożenie dostawcy, paczkę płatności czy partię wypłat bez zmiany Twoich szyn płatniczych.

Jedno i drugie - zależy od zadania. Jako narzędzie do sprawdzania odbiorcy odpowiada na pytanie „do kogo należy ten numer IBAN?” dla pojedynczego odbiorcy - przydatne dla zespołu finansowego lub płatnika przed wysłaniem pieniędzy. Jako API walidacji płatności wykonuje tę samą kontrolę w zautomatyzowanym przepływie, dzięki czemu każda płatność lub wypłata jest weryfikowana względem posiadacza rachunku, zanim zostanie wysłana.

„Know your payee” to praktyczny nawyk potwierdzania nazwy posiadacza rachunku przed zapłatą, zamiast polegania na danych z faktury czy e-maila. API zamienia ten nawyk w zautomatyzowany krok: nazwa jest porównywana z numerem IBAN, a Ty otrzymujesz jasną odpowiedź - zgodność, częściowa zgodność, brak zgodności lub weryfikacja niemożliwa - w czasie znacznie krótszym niż sekunda.

Confirmation of Payee (CoP) to brytyjski schemat weryfikacji nazw, a Verification of Payee (VoP) to schemat EPC stosowany w całej UE i SEPA. Jeśli potrzebujesz obu, szukaj dostawcy, który obsługuje schemat SEPA VoP przez jedną integrację i zwraca standaryzowane wyniki, dzięki czemu Twój kod nie zmienia się w zależności od rynku. RoxPay dostarcza VoP jako jedno API REST z kodami schematu, BIC instytucji odpowiadającej i czasem przetwarzania w każdej odpowiedzi.

Na pięć rzeczy. Zasięg: do jakich banków i krajów w całej SEPA dociera dostawca. Opóźnienie: czy wyniki mieszczą się niezawodnie w oknie płatności natychmiastowych. Dokładność: jak dopasowanie nazw radzi sobie z częściowymi zgodnościami oraz nazwami prawnymi i handlowymi. Kierunki: czy zapytania i odpowiedzi VoP przechodzą przez tę samą integrację. I wsparcie: kto monitoruje usługę i co się dzieje, gdy PSP odpowiadający jest nieosiągalny. Poproś na piśmie o strukturę odpowiedzi i kody błędów - powiedzą Ci więcej niż lista funkcji.

Rozgałęziaj logikę na podstawie kodu schematu, a nie wyświetlanej etykiety. W swoim interfejsie traktuj MTCH jako ciche przepuszczenie, CMTC jako łagodne ostrzeżenie, które pokazuje sugerowaną nazwę i prosi płatnika o potwierdzenie, a NMTC jako ostrzeżenie twarde, które blokuje automatyczną akceptację. NOAP nie jest ani jednym, ani drugim: oznacza, że weryfikacji nie udało się przeprowadzić, więc powiedz płatnikowi, że weryfikacja była niedostępna, i pozwól mu zdecydować. To właśnie rozdzielenie czterech kodów w kodzie sprawia, że zachowanie ostrzeżeń jest przewidywalne.

Tak, i warto. Punkt końcowy jest bezstanowy, więc to samo wywołanie weryfikuje odbiorcę w momencie tworzenia rekordu - na etapie wdrożenia sprzedawcy, dostawcy lub pracownika - a następnie ponownie bezpośrednio przed przelewem środków. Ponowna weryfikacja w momencie wypłaty wychwytuje dane bankowe zmienione po wdrożeniu, a właśnie tam najczęściej dochodzi do oszustwa polegającego na przekierowaniu wypłaty. Jeden punkt końcowy obsługuje oba momenty, więc nie utrzymujesz dwóch kontroli.

Tak. Dane uwierzytelniające do środowiska testowego wydaje się osobno od produkcyjnych, więc przed uruchomieniem produkcyjnym możesz przetestować na API przepływy zgodności, częściowej zgodności i braku zgodności. Przetestuj też ścieżki niepowodzeń - odpowiedź NOAP, 429 i 5xx - aby logika ponowień i ostrzeżeń była sprawdzona, zanim ruszą prawdziwe pieniądze. Te same dane uwierzytelniające odblokowują też panel RoxBusiness, w którym możesz przeprowadzać doraźne kontrole bez pisania kodu.

Otrzymujesz NOT_APPLICABLE (kod schematu NOAP) jako prawidłową odpowiedź 200, a nie błąd transportu. Oznacza to, że w tym momencie nie udało się przeprowadzić weryfikacji dla tego numeru IBAN. Traktuj to jako nieznany wynik, a nie awarię: poinformuj płatnika, że weryfikacja była niedostępna, i pozwól mu zdecydować, czy kontynuować. Prawdziwe awarie techniczne zwracają kody statusu 4xx i 5xx wraz z czytelnym dla maszyn kodem błędu.

PSP wysyłający to bank płatnika - to on wysyła zapytanie weryfikacyjne. PSP odpowiadający to bank odbiorcy - to on prowadzi rachunek i odpowiada wynikiem zgodności. Schemat EPC określa, jak oba podmioty wymieniają tę wiadomość; korzystając z API, tylko wysyłasz zapytanie i odczytujesz odpowiedź, więc nie budujesz samodzielnie komunikacji między PSP.

Nie. EPC publikuje specyfikacje API między PSP dla Verification of Payee, których PSP używają do wymiany zapytań i odpowiedzi. API VoP opakowuje tę komunikację: wysyłasz nazwę i numer IBAN przez REST i otrzymujesz standaryzowany wynik, kod schematu oraz BIC instytucji odpowiadającej - bez implementowania komunikacji schematu i bez integracji z każdym bankiem odpowiadającym.

Dopasuj tempo pętli do swojego okna wypłat, zamiast wysyłać cały plik wypłat naraz. Jeśli wysyłasz szybciej niż uzgodniona przepustowość, otrzymasz 429 - wycofaj się i ponów z opóźnieniem. W przypadku awarii 5xx ponów z tym samym identyfikatorem zewnętrznym, aby ponowienie nie utworzyło duplikatu weryfikacji. Przy 4xx popraw zapytanie: błędny numer IBAN, brak nazwy lub złe dane uwierzytelniające nie zadziałają przy ponowieniu.

API odpowiada na jedno pytanie - czy ta nazwa należy do tego numeru IBAN - i zwraca wynik schematu. Ten wynik to mocny sygnał do zasilenia własnych reguł ryzyka i oszustw: brak zgodności u odbiorcy, którego dane bankowe zmieniono niedawno, to dokładnie ten wzorzec, który warto eskalować. W logach trzymaj wynik weryfikacji i decyzję z kontroli oddzielnie, aby widzieć, co zatrzymało płatność.

Nie, odpowiadają na różne pytania. Walidacja IBAN sprawdza, czy numer jest poprawnie zbudowany - format kraju i cyfry kontrolne - ale nie mówi nic o tym, kto jest właścicielem rachunku. Verification of Payee pyta bank odbiorcy, czy nazwa należy do tego numeru IBAN. Stosuj oba: walidacja wychwytuje literówki przed wywołaniem, a weryfikacja wychwytuje prawidłowy numer IBAN, który należy do kogoś innego.