MagicPay koostatud juhend aitab maksetaristut valivatel ettevõtetel eristada ühendust, otsustamist ja töökorraldust. Vaatleme makset alates teenusepakkujale saadetud päringust kuni kinnitatud tulemuse kajastamiseni tellimuses ja finantsandmetes. Juhend esitab tehnoloogiapakkuja MagicPay vaatenurga ning annab projekti hindamiseks otsustusraamistiku.
1. Eristage ühendust ja koordineerimist funktsiooni järgi
Makselüüs on ühenduskiht, mis teisendab ettevõtte maksepäringu teenusepakkuja vormingusse, edastab selle ja toob vastuse tagasi. Maksete orkestreerimine koordineerib sobiva ühenduse valikut, tulemusele järgnevaid samme ning protsessi jälgimist. Need ei ole teineteist välistavad tootekategooriad: makselüüs võib pakkuda ka suunamist ja töökorralduslikke funktsioone. Määrake piir iga sammu vastutuse, mitte tootenime järgi.
- Ühenduse küsimus: millise API kokkuleppe alusel ja millisele pakkujale päring saadetakse?
- Orkestreerimise küsimus: miks see ühendus valiti ja milline tulemus määrab järgmise sammu?
2. Kaardistage ühe tellimuse makseteekond
Looge tellimuse ja makse viited, valige sobiv ühendus ning saatke päring. Olenevalt voost võib klient vajada autentimist; tulemus võib saabuda kohe või jääda ootele. Kliendi jõudmine tagasisuunamise lehele ei tõenda veel makset. Makse olekut uuendab kontrollitud serveriteavitus või dokumenteeritud olekupäring. Autoriseerimine, summa lõplik debiteerimine ja raha laekumine võivad olla eri etapid; siduge tellimuse täitmine õige kinnitatud etapiga.
3. Alustage suunamist sobivustingimustest
Suunamine määrab enne katse algust kasutatava teenusepakkuja. Valuuta, makseviis, kaupmehekonto ja pakkuja leping piiravad esmalt sobivate valikute hulka; prioriteedi- või kulureegel rakendub selle hulga sees. Mitme ühenduse olemasolu ei tähenda iseenesest kasutatavat varuvarianti. Suunamisreegli hindamisel küsige, millal see rakendub, kus otsus talletatakse ja kes saab vigase reegli tagasi võtta.
4. Lahendage ebaselge tulemus enne korduskatset
Ajalõpp ei tõenda, et teenusepakkuja päringut ei töödelnud. Salvestage olemasolev katse ning küsige pakkuja viite abil olekut või oodake kontrollitud teavitust. Uue maksepäringu saatmine teisele pakkujale ajal, mil esimese tulemus on teadmata, võib tekitada kaks edukat makset. Sama päringu tehnilisel kordamisel järgige pakkuja idempotentsuse tingimusi: sama toiminguvõtit ja parameetreid kasutatakse ainult toetatud ulatuses ning säilitusaja jooksul. Ühe pakkuja võti ei kõrvalda teise pakkuja juures tekkivat topelttehingut.
- Eristage ajutist sideviga lõplikust keeldumisest; iga keeldumine ei luba korduskatset.
- Alustage uut katset ainult siis, kui eelmine tulemus ja pakkuja reeglid seda lubavad; määrake katsete ja ooteaja piirid.
- Kui tulemus jääb ebaselgeks, suunake makse uurimisele; uus võti ei lahenda makse olekut.
5. Kavandage tehingukirjed maksevastusest eraldi
Tellimuse viide, iga katse tunnus, pakkuja viide, summa, valuuta, otsuse põhjus ja olekumuutused peavad olema koos jälgitavad. Kontrollige teavitusi pakkuja meetodiga; korduvad või vales järjekorras sündmused ei tohi tellimust kaks korda lõpetada. See jälgimiskirje ei asenda raamatupidamise pearaamatut ega pangalaekumiste võrdlust. Eristage tagasimakse taotlust tehtud tagasimaksest ning edukat makset laekunud rahast. Määrake vastutaja tellimuse, pakkuja ja finantsandmete erinevuste lahendamiseks.
6. Valige kiht tegeliku töökoormuse järgi
Ühe pakkuja ja selge olekuvooga ettevõttele võib piisata ühendusest ning põhilisest olekujälgimisest. Mitme pakkuja, muutuvate suunamisreeglite, lahendamata maksete järjekorra või killustatud tagasimaksete jälgimise korral hinnake orkestreerimise vastutusi eraldi. Rohkem kihte ei ole alati parem: lisanduvad reeglite haldus ja uued tõrkekohad. Lähtuge meeskonna praegusest käsitööst ning töökorralduslikust vastutusest, mida ta suudab kanda, mitte tootesildist.
- Milliseid otsuseid tehakse praegu käsitsi ja milliste andmete alusel?
- Kust alustab meeskond ootele jäänud makse uurimist ja kes selle eest vastutab?
- Mida muudab uue pakkuja lisamine tellimuste ja finantside töövoos?
7. Katsetage üleminekut olemasolevate maksetega
Kaardistage senised viited, pooleliolevad maksed, tagasimaksevood ja kirjete eksport. Ärge eeldage salvestatud maksevahendite ülekantavust; kontrollige tokenite kasutusulatust ja vajalikke lubasid asjaomase pakkujaga. Katsetage kontrollitud testtellimusega edu, lõplikku keeldumist, ajalõppu, hilinenud teavitust ja korduvat teavitust. Leppige kokku, kes jälgib tagasipööramisel pooleliolevaid katseid. Varirežiimis hindamine peab võrdlema ainult otsuseid, mitte algatama sama päristellimuse eest kaht makset.
- Kes vastutab vanasse süsteemi jäänud maksete päringute, tagasimaksete ja finantsvõrdluse eest?
- Milline vastuvõtukriteerium peatab ülemineku ning käivitab reegli või ühenduse tagasipööramise?
- Kas meeskond suudab näidismakset tellimusest finantskirjeni jälgida?
8. Hinnake MagicGate'i selle raamistiku kaudu
MagicPay B2B tehnoloogiataristu MagicGate hõlmab nii teenusepakkujate ühendusi kui ka maksete orkestreerimist. Juhendi üldine eristus ei piira seega MagicGate'i ainult ühenduskihiga. Täpsustage konkreetse tellimusteekonna abil projekti ühendused, suunamis- ja korduskatsetingimused, olekupäringud ning tehingukirjed. Raha liigutava tegevusloaga asutuse roll, kontod ja lepingud tuleb määrata eraldi; tehnoloogiakiht ei asenda seda rolli.