Többoldalú piactér- és partneri működési platform mérnöki megvalósítása

A Scape egy böngészhető ügyfélpiacteret, fiók nélküli foglalási utat, szerepkörökkel védett partneri portált és adminisztrációs konzolt kapcsol össze. Ezek ugyanannak az üzleti állapotnak egymást kiegészítő nézetei, nem utólag összekapcsolt külön termékek.

Az ügyfelek kategória- és dátumszűrésből indulhatnak, majd egy élményoldalon, az elérhető időpontokon és egy korlátozott férőhely-foglaláson át juthatnak el a szolgáltató által hosztolt fizetésig, hagyományos fiók létrehozása nélkül. A partnerek megkapják a kínálatuk működtetéséhez szükséges átláthatóságot. A platform üzemeltetői pedig megtartják a pénzügyi döntésekhez, kivételekhez és megfelelőségi munkához szükséges döntési jogot.

A többoldalú platformnak úgy kell összehangolnia az eltérő felelősségeket, hogy ne adjon minden szerepkörnek azonos kontrollt. Az ügyfélbizalomnak tartós fiók nélkül is működnie kell. A kapacitásnak ellen kell állnia az egymással versengő foglalási kéréseknek. A fizetés beszedése nem téveszthető össze a teljesítéssel megszolgált értékkel. A különböző üzleti modellek pedig különböző számlázási kötelezettségeket teremtenek.

A mérnöki feladat ezért nem oldalak halmaza volt. Olyan tranzakciós modellre volt szükség, amely egységes információt vetít az ügyfél-, partneri és adminisztratív folyamatokba, miközben megőrzi a platformhoz tartozó döntéseket.

Az ügyfélpiactér, a partneri működési portál és a Scape adminisztrációs konzolja közös tranzakciós mag fölött helyezkedik el. Ez a mag kezeli a kapacitásfoglalást, a foglalási állapotot, a teljesítést, a visszatérítést és a megfelelőségi szolgáltatásokat. Alatta a pénzügyi bizonyíték alapja húzódik: a rögzített pénzügyi tények, a változtathatatlan foglalási kontextus és a teljesítési bizonyíték a fölötte lévő működési nézeteket támasztják alá, anélkül hogy egy negyedik silót hoznának létre.

A Scape kilencállapotú, védett átmenetekkel működő foglalási állapotgépet használ, így a foglalás meghatározott működési állapotokon halad át, nem informális státuszváltásokon. Az adatbázisszintű zárolással védett kapacitásfoglalás megakadályozza, hogy versengő kérések ugyanazt a férőhelyet foglalják el. A foglalás, a kapacitásfoglalás, a visszatérítés, a napló, a kifizetés és az értesítések hatásai idempotensek, a pénzösszegek pedig egész HUF-értékként, következetes végösszegekkel jelennek meg.

A szolgáltatói visszahívásokat a szerver ismét ellenőrzi. A visszaigazolás és a tartós outboxba sorolás ugyanabban a tranzakcióban történik, így a foglalás nem függ az e-mail kézbesítésének sikerétől.

A fő út átláthatóvá teszi az ügyfél tevékenységét, miközben a mag rögzíti a működéshez fontos állapotokat. A lemondás, a visszatérítés és az átfoglalás irányított kivételi ágon kap helyet. Az adminisztrátor által jóváhagyott visszatérítési kivétel a jóváhagyás után automatikusan végrehajtódik. A T-72 szabály visszaigazolási időablak és adminisztratív továbbítási szabály, nem visszatérítési jogosultság. Az adminisztratív átfoglalás ma elérhető a motorban; az ügyféloldali, átfoglalást előtérbe helyező modell továbbra is tervezett munka.

A partneri portál egy működési konzol alapja, nem pedig annak állítása, hogy minden partneri feladat önkiszolgáló módon elvégezhető. A szerepkörökkel védett felhasználók a saját foglalásaikból számított dashboard-mutatókat láthatnak: GMV-t, 15%-os jutalékkulcs-paramétert és nettó értéket, közelgő időpontokat és előzményeket. Áttekinthetik a résztvevői szintű foglalásokat, visszaigazolhatják a kapacitásfoglalásokat, jelenthetik az elmaradást az adminisztráció jóváhagyási lánca számára, karbantarthatják a kínálat részleteit, és megnézhetik ajánlatonként a kihasználtságot.

A pénzügyi nézet ugyanilyen tudatos: a partnerek futó naplóban láthatják a bruttó, a jutalék és a nettó értékeket, adataikat CSV-be exportálhatják, és áttekinthetik a kifizetési, jutalékszámla-, visszatérítési és foglalási számlamegfelelőségi előzményeket. Nyilvános márkaoldalon is megjelennek.

A visszatérítésről nem a partnerek döntenek. Ezt a műveletet szándékosan eltávolítottuk, hogy az átláthatóság a partnernél, a pénzről szóló döntési jog pedig a Scape-nél maradjon. A jelenlegi rendszeren túl tervezett: önkiszolgáló belépés, publikálás, időpontok létrehozása és szerkesztése, elérhetőségi eszközök, résztvevői export és tartós márkaarculat.

A beszedés az ellenőrzött sandbox fizetési úton automatizált. A megszolgált érték elszámolása csak teljesítéssel kezdődik. A mag hozzáfűzéses pénzügyi bizonyítékot, a változtathatatlan foglalási kontextusról készült pillanatképeket, pontosan egyszer rögzített teljesítési bizonyítékot és az ebből következő nyolcnapos számlázási kötelezettséget rögzít. A visszatérítési bizonyíték a jóváhagyott kivétel visszafordításának szabályait rögzíti.

A havi elszámolási ciklus a következő ciklusként tervezett, nem automatizált kifizetési vagy számlázási rendszerként bemutatott elem. A különbségtétel egy lényegi üzleti igazságot véd: a fizetés beérkezése nem azonos a megszolgált érték elszámolásával.

A Scape adminisztráció a partneri átláthatóság ellenpárja: két konzol, egy mag, elkülönített döntési jog. A 41 végpontból álló adminisztratív felület támogatja a foglalások pénzügyi riportolását és CSV-exportját, a kifizetés jóváhagyását olyan könyvelési lépésként, amely banki hivatkozással jelöli kifizetettnek a tételt, a visszatérítés felülbírálatát és jóváhagyás utáni végrehajtását, valamint az elmaradási jelentések jóváhagyását vagy elutasítását.

Az adminisztrátorok emellett ellenőrzik, kézbesítik vagy elengedik a számlamegfelelőségi rekordokat; működtetik az áfafigyelő nézetet, miközben jelzik annak levezetési korlátait; szerkesztőségi tartalmat gondoznak; és felügyeleti olvasási nézeteket használnak foglalási, napló- és számlázási munkához. A kifizetési modell offline banki átutalási döntést rögzít; nem állít banki automatizálást.

Barion — Sandbox: Magyar fizetési szolgáltatói integráció hosztolt beszedéshez, HMAC-aláírt visszahívásokhoz és visszatérítési hívásokhoz; az út sandboxban ellenőrzött.

Billingo — Korlátozott: Jutalékszámla-adapter újrapróbálási és korrekciókezeléssel. A Scape-Direct számlázás tervezett, nem szállított képesség.

Resend tartós outboxon keresztül — Korlátozott: A tranzakciós e-mail szolgáltatófüggetlen feldolgozási folyamatot használ újrapróbálással és dead-letter kezeléssel.

WordPress — Korlátozott: Headless tartalmi sík szolgálja ki a blog- és jogi tartalmi felületeket tartalékkezeléssel.

A kiválasztott felületképek az ügyfélfoglalási utat, a partneri foglalási átláthatóságot, a napló transzparenciáját és az adminisztrációs oldali megfelelőségi munkát mutatják. Minden kép helyi demóadatokra épülő felületet mutat, publikálás előtt kitakarva, és kizárólag akkor használható, ha egy meghatározott platformképességet támaszt alá. Ha egy kép nem őrzi meg ezt az egyértelműséget, a felületleltár marad a megfelelő bizonyíték.

A Scape a SALVOC irányított AI-mérnöki megközelítésével készült: az architektúra, a megvalósítás, a független műszaki felülvizsgálat, a determinisztikus ellenőrzés és az emberi döntési jog elkülönült. A módszert a Governed AI Engineering esettanulmány dokumentálja; itt a fókusz azon a többoldalú üzleti platformon marad, amelyet ez lehetővé tett.

A Scape irányított helyi fejlesztési és sandbox környezetben, feltöltött demonstrációs adatokkal jelenik meg; ezek a státuszok rendszerképességet írnak le, nem kereskedelmi működést vagy üzleti eredményeket.

Az alábbi „Szállítva”, „Tervezve” és „Ütemterv” státuszú sorok elválasztják a kialakult képességeket a következő működési lépésektől, anélkül hogy bármelyiket felnagyítanák.