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 volumenterő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 payloadokat é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-payloadot é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 blokkoldja 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. 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.