A Verification of Payee API

Igen. Az ellenőrző hívás szinkron módon válaszol, jellemzően jóval egy másodperc alatt, és tartalmazza a válaszadó bank BIC-jét és a PSP feldolgozási idejét, így figyelheted a teljesítményt.

A hívásokat HTTPS-en keresztül, bearer tokennel hitelesítjük. Ad hoc ellenőrzésekhez kód írása nélkül a RoxBusiness irányítópultot is használhatod.

Egy normalizált eredmény (MATCH, CLOSE_MATCH, NO_MATCH, NOT_APPLICABLE), a SEPA séma egyezéstípus-kódja, egy ellenőrzési azonosító, a válaszadó BIC, a feldolgozási idő és az opcionális külső azonosítód.

Igen - hívd meg a végpontot rekordonként, hogy egy egész szállítói vagy kedvezményezett-fájlt ellenőrizz egy kifizetési kör előtt. Nagy áteresztőképességre épül.

Igen. A végpont állapotmentes, így bármikor meghívhatod, amikor létrejön egy kedvezményezett - például egy eladó vagy szállító ügyfélbevonásakor -, és újra közvetlenül minden kifizetés előtt. A kifizetéskori újraellenőrzés kiszűri az ügyfélbevonás után megváltozott bankadatokat, ahol a számla- és kifizetésátirányításos csalás általában történik.

Az ellenőrzés rekordonkénti REST-hívás, így a több ezer kedvezményezettet tartalmazó kifizetési fájlt kötegként kezeled: fuss végig a fájlon, hívd meg a végpontot rekordonként, és gyűjtsd össze az eredményeket, mielőtt elindítod a kört. Mivel az API nagy áteresztőképességre épül, a ciklus ütemét a saját indítási ablakodhoz igazíthatod, ahelyett hogy a bankonkénti ügyfélbevonás korlátozna. Beszélj velünk a volumenteidről, és együtt méretezzük az áteresztőképességet.

Igen. Ugyanaz az ellenőrzés elérhető a RoxBusiness irányítópulton, így egy pénzügyi vagy operatív csapat egyetlen kedvezményezettet is ellenőrizhet - egy „ismerd a kedvezményezetted” ellenőrzést pénz küldése előtt -, míg a fejlesztők az API-t használják automatizált folyamatokhoz.

Igen. Az ellenőrzés a beküldött nevet veti össze a bejegyzett számlatulajdonossal, akár magánszemélyről, akár cégről van szó, és a RoxPay SEPA Direct Debit felhatalmazási folyamatában előzetes ellenőrzésként használjuk.

A NO_MATCH nem szállítási hiba - érvényes 200-as válasz, amely azt jelzi, hogy a név nem tartozik az IBAN-hoz. Kezeld kemény megállásként a felületedben vagy a kifizetési körben: mutass egyértelmű figyelmeztetést, blokkold az automatikus jóváhagyást, és hagyd, hogy a felhasználó újra ellenőrizze a kedvezményezettet küldés előtt.

A CLOSE_MATCH (sémakód: CMTC) azt jelenti, hogy a név majdnem jó - hiányzik egy középső név, vagy a bejegyzett név eltér a kereskedelmi névtől. A válasz tartalmazza az ellenőrzött számlatulajdonos-nevet, így javaslatként megmutathatod, és megerősítést kérhetsz a fizetőtől a fizetés elutasítása helyett.

Jogi személyeknél a séma lehetővé teszi az ellenőrzést a szervezet azonosítója (például olasz Partita IVA / Codice Fiscale) alapján is, a név mellett. Az azonosítót a kérésben küldöd el, és az API visszaadja a szabványos egyezési eredményt - hasznos, amikor a bejegyzett név és a kereskedelmi név eltér.

Igen. Egy kifizetési körhöz fuss végig a szállítói vagy bérfájlon, és hívd meg az ellenőrző végpontot rekordonként, mielőtt elindítod a köteget. Nagy áteresztőképességre épül, így a pénzügyi csapatok minden kifizetési kör előtt tömegesen validálhatják az IBAN-okat a nevekkel szemben.

Igen. Egy JSON-kérést küldesz a kedvezményezett nevével és IBAN-jával, és visszakapod az eredményt, az ellenőrzött nevet (közeli egyezésnél) és a válaszadó BIC-et. Nézd meg a teljes kérést és választ a VoP-példánkban, vagy a kérés- és válaszüzeneteket és sémakódokat az API-dokumentációban.

Tekintsd az ellenőrző hívást egy plusz lépésnek, mielőtt a fizetést engedélyezik. Hitelesíts bearer tokennel, POST-old a kedvezményezett nevét és IBAN-ját, olvasd el az eredményt, majd ágazz el: MATCH esetén haladj tovább, CLOSE_MATCH esetén mutasd meg a javasolt nevet és kérj megerősítést, NO_MATCH esetén blokkold az automatikus jóváhagyást, NOT_APPLICABLE esetén pedig hagyd, hogy a fizető döntsön. Mivel a végpont állapotmentes, ugyanaz a hívás beilleszthető a fizetési folyamatba, a szállítói ügyfélbevonásba, egy kifizetési körbe vagy egy kifizetési kötegbe anélkül, hogy a fizetési csatornáidon változtatnál.

Mindkettő, a feladattól függően. Kedvezményezett-ellenőrzőként arra válaszol, hogy „kihez tartozik ez az IBAN?” egyetlen kedvezményezettnél - hasznos egy pénzügyi csapatnak vagy a fizetőnek pénz küldése előtt. Fizetésvalidálási API-ként ugyanezt az ellenőrzést futtatja egy automatizált folyamatban, így minden fizetés vagy kifizetés a számlatulajdonossal szemben validálva indul el.

A „know your payee” az a gyakorlati szokás, hogy fizetés előtt megerősítjük a számlatulajdonos nevét, ahelyett hogy egy számlán vagy e-mailben szereplő adatokban bíznánk. Az API ezt a szokást automatizált lépéssé alakítja: a nevet összeveti az IBAN-nal, és jóval egy másodperc alatt egyértelmű választ ad - egyezés, közeli egyezés, nincs egyezés vagy nem lehetséges.

A Confirmation of Payee (CoP) a brit névellenőrzési séma; a Verification of Payee (VoP) az EPC sémája, amelyet az egész EU-ban és a SEPA-térségben használnak. Ha mindkettőre szükséged van, olyan szolgáltatót keress, amely egyetlen integrációval lefedi a SEPA VoP sémát, és a szabványosított eredményeket adja vissza, így a kódod nem változik piaconként. A RoxPay a VoP-ot egyetlen REST API-ként nyújtja, minden válaszban a sémakódokkal, a válaszadó BIC-cel és a feldolgozási idővel.

Öt dolgot. Lefedettség: mely bankokat és országokat éri el a szolgáltató a SEPA-térségben. Késleltetés: az eredmények megbízhatóan beleférnek-e az azonnali fizetés ablakába. Pontosság: hogyan kezeli a névegyeztetés a közeli egyezéseket, valamint a bejegyzett és a kereskedelmi neveket. Irányok: a kérelmező és a válaszadó VoP ugyanazon az integráción keresztül megy-e. És támogatás: ki figyeli a szolgáltatást, és mi történik, ha egy válaszadó PSP nem érhető el. Kérd írásban a válaszüzenet felépítését és a hibakódokat - ezek többet elárulnak egy funkciólistánál.

A sémakódra ágazz el, ne a megjelenített címkére. A felületedben kezeld az MTCH-t csendes átengedésként, a CMTC-t enyhe figyelmeztetésként, amely megmutatja a javasolt nevet és megerősítést kér a fizetőtől, az NMTC-t pedig kemény figyelmeztetésként, amely blokkolja az automatikus jóváhagyást. A NOAP egyik sem: azt jelenti, hogy az ellenőrzést nem sikerült elvégezni, ezért jelezd a fizetőnek, hogy az ellenőrzés nem volt elérhető, és hagyd, hogy döntsön. Az, hogy a négy kódot külön kezeled a kódodban, teszi kiszámíthatóvá a figyelmeztetések működését.

Igen, és érdemes is. A végpont állapotmentes, így ugyanaz a hívás ellenőrzi a kedvezményezettet a rekord létrehozásakor - egy eladó, szállító vagy munkavállaló ügyfélbevonási lépésénél -, majd újra közvetlenül azelőtt, hogy a pénz elindul. A kifizetéskori újraellenőrzés az, ami kiszűri az ügyfélbevonás után megváltozott bankadatokat, ahol a kifizetésátirányításos csalás általában történik. Egyetlen végpont szolgálja ki mindkét pillanatot, így nem tartasz fenn két ellenőrzést.

Igen. A sandbox hitelesítő adatait a produkciós adatoktól külön adjuk ki, így az élesítés előtt tesztelheted az egyezés, a közeli egyezés és a nincs egyezés folyamatait az API-n. Teszteld a nehéz utakat is - egy NOAP választ, egy 429-et és egy 5xx-et -, hogy az újrapróbálkozási és figyelmeztetési logikád bizonyított legyen, mielőtt valódi pénz elindul. Ugyanezek a hitelesítő adatok a RoxBusiness irányítópultot is megnyitják, ahol kód írása nélkül futtathatsz ad hoc ellenőrzéseket.

NOT_APPLICABLE (sémakód: NOAP) választ kapsz érvényes 200-as válaszként, nem szállítási hibaként. Ez azt jelenti, hogy az ellenőrzést abban a pillanatban nem sikerült elvégezni arra az IBAN-ra. Kezeld ismeretlenként, ne hibaként: tájékoztasd a fizetőt, hogy az ellenőrzés nem volt elérhető, és hagyd, hogy eldöntse, folytatja-e. A valódi technikai hibák 4xx és 5xx állapotkódokat használnak géppel olvasható hibakóddal.

A kérelmező PSP a fizető bankja - ő küldi az ellenőrzési kérést. A válaszadó PSP a kedvezményezett bankja - nála van a számla, és ő válaszol az egyezési eredménnyel. Az EPC séma határozza meg, hogyan cseréli ki a két fél ezt az üzenetet; az API-val csak elküldöd a kérést és elolvasod a választ, így a PSP-k közötti üzenetváltást nem neked kell megépítened.

Nem. Az EPC teszi közzé a Verification of Payee inter-PSP API specifikációit, amelyeket a PSP-k a kérések és válaszok kicserélésére használnak. Egy VoP API ezt az üzenetváltást csomagolja be: REST-en elküldesz egy nevet és egy IBAN-t, és megkapod a szabványos kimenetet, a sémakódot és a válaszadó BIC-et, anélkül hogy megvalósítanád a séma üzenetváltását, vagy minden válaszadó bankkal külön integrálódnál.

A ciklust az indítási ablakodhoz igazítsd, ne egyszerre küldd ki az egész kifizetési fájlt. Ha gyorsabban küldesz a megállapodott áteresztőképességednél, 429-et kapsz - vegyél vissza, és késleltetéssel próbáld újra. 5xx hiba esetén ugyanazzal a külső azonosítóval próbáld újra, hogy az újrapróbálkozás ne hozzon létre duplikált ellenőrzést. 4xx esetén javítsd a kérést: egy hibás formátumú IBAN, egy hiányzó név vagy rossz hitelesítő adatok újrapróbálkozásra sem fognak sikerülni.

Az API egyetlen kérdésre válaszol - ehhez az IBAN-hoz tartozik ez a név -, és visszaadja a séma kimenetét. Ez az eredmény erős jelzés a saját csalás- és kockázati szabályaidhoz: egy nincs egyezés olyan kedvezményezettnél, akinek nemrég változtak meg a bankadatai, pontosan az a minta, amit érdemes kiemelni. A naplóidban tartsd külön az ellenőrzés eredményét és a szűrési döntésedet, hogy lássd, melyik állította meg a fizetést.

Nem, más kérdésre válaszolnak. Az IBAN-validálás azt ellenőrzi, hogy az IBAN formailag helyes-e - országformátum és ellenőrző számjegyek -, de semmit nem mond arról, kié a számla. A Verification of Payee a kedvezményezett bankjától kérdezi meg, hogy a név ehhez az IBAN-hoz tartozik-e. Futtasd mindkettőt: a validálás a hívás előtt kiszűri az elgépeléseket, az ellenőrzés pedig kiszűri azt az érvényes IBAN-t, amely valaki máshoz tartozik.