Az Ostva amerikai piacterén eszközöket lehet bérelni és feladatokra jelentkezni. Megmutatjuk, miért kellett saját naptárat írnunk, hogyan kötöttük a bérlést személyazonosításhoz és miért csak a lezárás után kap pénzt a bérbeadó.
Egy bérlő kiválaszt egy eszközt és néhány szabad napot a naptárban. Megnézi a bérleti díjat és a kauciót, majd elindítja a foglalást. A tulajdonos a sikeresen lezárt bérlés után kapja meg a neki járó összeget.
A felhasználónak ez egyszerű folyamat. A háttérben viszont össze kell kapcsolni az eszköz foglaltságát, a bérlő személyazonosítását, a kártyás fizetést, a visszaadást és az elszámolást és ha bármelyik lépésnél gond van, az üzemeltetőnek be kell tudnia avatkozni.
Az Ostva amerikai piacra készült online piactér, amelyben a felhasználók eszközöket adhatnak bérbe, illetve feladatokat hirdethetnek meg és vállalhatnak el. A Petadev a nulláról fejlesztette hozzá az iOS- és Android-alkalmazást, a háttérrendszert, a webes adminfelületet és a bemutatkozó weboldalt.
Ebben az esettanulmányban azt mutatjuk be, miért kellett saját foglalási naptárat írnunk, hogyan kötöttük a bérlést személyazonosításhoz és a kifizetést a lezáráshoz és mit hagytunk ki az első verzióból.
Az Ostva projekt röviden:
| Szempont | Megvalósítás |
|---|---|
| A piactér célja | Eszközbérlés és feladatvállalás az amerikai piacon |
| A Petadev feladata | iOS- és Android-app, backend, webes adminfelület és bemutatkozó weboldal |
| Arculat és felülettervezés | Közös munka a megrendelővel |
| Mobiltechnológia | React Native és Expo |
| Fizetés | Stripe Connect |
| Személyazonosítás (KYC) | Onfido |
| A mobilalkalmazás fejlesztési ideje | Körülbelül öt hónap |
| Állapot a cikk írásakor | Bevezetés Atlanta környékén, az első regisztrációkkal, foglalásokkal és tranzakciókkal |
Kétféle ügylet, egy rendszer
Az Ostván kétféle ügylet jön létre. Az egyikben valaki egy eszközt szeretne használni meghatározott ideig. A másikban munkához keres segítséget, például takarításhoz, ereszjavításhoz vagy korrepetáláshoz.
A kettőnek sok közös eleme van: felhasználók, hirdetések, fizetés, elszámolás. A teljesítés viszont mást jelent. Bérlésnél az időszak, a foglaltság és az eszköz visszaadása számít. Feladatnál az, hogy a vállalt munka elkészült-e és ezt mindkét fél jóváhagyta-e.
Ezért a tervezést nem a képernyőkkel kezdtük, hanem négy kérdéssel: ki kezdeményezhet ügyletet, mikor kell fizetnie, mi számít teljesítésnek és mikor válik kifizethetővé az összeg. Az Ostván a sikeres fizetés és a sikeresen lezárt ügylet két külön esemény és a rendszer mindkettőt követi.
Hogyan működik az eszközbérlés?
A bérlés az eszköz adatlapjáról indul.
- Időszak kiválasztása. A naptár az aktuális foglaltság alapján mutatja, mely napok szabadok.
- Az összeg áttekintése. A bérlő látja a kiválasztott időszak díját és a kauciót.
- Foglalás. Foglaláskor a rendszer zárolja az összeget a bérlő kártyáján, a kiválasztott napokat pedig a naptárban.
- Elfogadás. A foglalást a bérbeadónak el kell fogadnia. A tényleges terhelés csak ezután történik meg.
- Bérlés és visszaadás. Az ügylet lezárásához mindkét fél visszajelzése kell.
- Elszámolás. A lezárás után a bérbeadó megkapja a neki járó összeget. A kaució rendezése ahhoz kötött, hogy az eszköz megfelelő állapotban került-e vissza.
A bérbeadó tehát nem a foglalás pillanatában jut a pénzéhez, a bérlő kártyáján pedig az elfogadásig csak zárolás van. Ha vita alakul ki, az ügyet az adminisztrátor vizsgálja meg.
Miért kellett saját naptárat írnunk?
A projekt legtöbb fejtörést okozó része a foglalási naptár volt. Három okból.
A kész komponensek nem tudták, amire szükségünk volt. Olyan felület kellett, amely az eszköz aktuális foglaltságát mutatja, engedi az időszak kijelölését és a bérlőnek és a bérbeadónak is érthető. A React Native-hez elérhető kész naptárkomponensekkel ezt nem tudtuk megoldani, ezért saját komponenst írtunk.
A függő foglalás is foglalja a napokat. A foglalást a bérbeadónak el kell fogadnia, tehát a kérés elküldése és az elfogadás között van egy köztes állapot. Az Ostván erre az időre a rendszer zárolja az érintett napokat: amíg a kérés függőben van, más nem foglalhat ugyanarra az időszakra. A naptárnak így nemcsak a végleges foglalásokat kell ismernie, hanem a függőben lévőket is.
Ketten ugyanarra a hétvégére. Egy piactéren előfordul, hogy két bérlő ugyanabban a percben nézi ugyanazt az eszközt és mindketten szabadnak látják ugyanazt az időszakot. A rendszer ezt kezeli: a két kérés közül csak az egyikből lesz foglalás. A tervezésnél ez volt az egyik eset, amelyet külön végig kellett gondolni.
A naptár egy bérlési piactéren nem csak felületi elem: a foglalási szabályok egy része benne van. Ezért a tervezésnél és a becslésnél is külön tételként érdemes kezelni.
Személyazonosítás (KYC): ki viheti el más eszközét?
Az Ostván csak az bérelhet, aki elvégezte a személyazonosítást. Ehhez az Onfido szolgáltatását integráltuk.
Az üzleti ok egyszerű: a tulajdonos egy idegennek adja át a tárgyát és ezt csak akkor teszi meg, ha a platform tudja, ki az illető.
A fejlesztési feladat nem maga az integráció volt, hanem az, hogy az eredmény valóban jogosultság legyen. Az azonosítás állapota a felhasználó fiókjához kapcsolódik és a rendszer ez alapján engedi vagy állítja meg a foglalást. Azonosítás nélkül bérlést nem lehet indítani.
Az azonosítás csökkenti a visszaélések esélyét, de önmagában nem old meg egy vitát. Ahhoz a foglalási szabályok, a kétoldali visszaigazolás és az adminisztrátori beavatkozás is kell.
Stripe Connect: zárolás, terhelés és kifizetés
Az Ostva fizetési rendszerét Stripe Connectre építettük. Foglaláskor a rendszer zárolja az összeget a bérlő kártyáján, a tényleges terhelés a foglalás elfogadása után történik, a bérbeadó kifizetése pedig az ügylet lezárásához kötött.
A Stripe Connect kifejezetten több szereplős platformokhoz készült: kezeli, hogy a pénz a vásárlótól a szolgáltatóhoz kerüljön, a platform jutalékának levonásával. Azt viszont nem tudja, mikor tekinthető egy bérlés lezártnak. Ezt az alkalmazásnak kell megmondania.
Az Ostván ezt kellett meghatároznunk:
- ki fizet az adott ügyletben és mekkora összeget;
- mi számít lezárásnak bérlésnél és mi feladatnál;
- hogyan oszlik meg az összeg a bérbeadó vagy a feladatot végző fél és a platform jutaléka között;
- mi történik a zárolt összeggel, ha a foglalást nem fogadják el, vagy az ügylet nem jut el a lezárásig.
A zárolásnak van egy gyakorlati korlátja, amellyel minden hasonló piactér szembesül: a kártyás zárolás csak korlátozott ideig él. A jóval előre vagy hosszabb időre szóló bérlésekhez és a kaució kezeléséhez ezért külön szabályokat alakítottunk ki. Aki piacteret tervez, annak érdemes ezeket már a specifikáció írásakor végiggondolnia.
A felhasználó ebből annyit lát, hogy foglaláskor zárolás történik a kártyáján, a bérbeadó pedig csak a sikeresen lezárt ügylet után kap kifizetést.
Hogyan működik a feladatvállalás?
A feladatoknál valaki meghirdeti, mire van szüksége és azok jelentkeznek, akik elvállalnák.
A feladatot végző fél kifizetése a kétoldali jóváhagyáshoz kötött. A különbség a lezárás tartalmában van. Bérlésnél a visszaadás és a kaució rendezése is része az ügyletnek. Feladatnál az számít, hogy mindkét fél jóváhagyta-e a munka elkészültét.
A két terület ugyanarra az elszámolási logikára épül, a felhasználói folyamatot viszont külön kellett megtervezni mindkettőhöz.
Mire kell az adminfelület?
A szükséges felhasználói jóváhagyások után a rendben végigfutó ügyletek elszámolása automatizált. Lemondásnál, fizetési hibánál vagy vitatott teljesítésnél viszont embernek kell döntenie.
Ehhez külön webes adminfelületet fejlesztettünk, ahol az üzemeltető megnézheti a problémás ügyletet és intézkedhet. Ez az első verziónak is része volt: az automatizált folyamatok mellett is kell valaki, aki egy elakadt ügyletet meg tud nézni és le tud zárni.
Milyen technológiákkal készült?
| Rendszerelem | Technológia |
|---|---|
| iOS- és Android-alkalmazás | React Native, Expo |
| Webes adminfelület | React, Next.js |
| Háttérrendszer | Node.js, MySQL, Firebase |
| Fizetés | Stripe Connect |
| Személyazonosítás | Onfido |
| További integrált szolgáltatások | Twilio, Brevo |
A React Native és az Expo közös fejlesztési alapot adott az iOS- és az Android-alkalmazáshoz. Arról, hogyan dolgozunk mobilprojekteken, a mobilalkalmazás-fejlesztés oldalunkon írunk részletesen.
A nehezebb feladat nem az egyes technológiák használata volt, hanem az, hogy ugyanannak az ügyletnek az állapota egyezzen a telefonon, a szerveren és a Stripe-nál.
Mit hagytunk ki az első verzióból?
Az első verzióban a piactér csak mobilalkalmazásból használható. A böngészőből elérhető, teljes webes piacteret későbbre hagytuk.
A bemutatkozó weboldal és az adminfelület ettől függetlenül elkészült, mert más a dolguk: az egyik bemutatja a terméket, a másik az üzemeltetést szolgálja.
Ez az induló fejlesztés terjedelméről szóló döntés volt: a foglalást, az azonosítást és a fizetést mobilon építettük meg teljesen és nem készítettük el ugyanazt még egyszer böngészőre. Egy piactér első verziójánál a felületeket ugyanúgy rangsorolni kell, mint a funkciókat.
Hol tart most az Ostva?
A mobilalkalmazás fejlesztése körülbelül öt hónapig tartott. Ez ennek a projektnek az ideje: más piactérnél a szerepkörök, a foglalási szabályok és az integrációk száma mást adhat ki.
A cikk írásakor az Ostva bevezetése Atlanta környékén zajlik. Megvannak az első letöltések, regisztrációk, foglalások és tranzakciók.
Az Ostva külső megrendelésként indult. Az átadás után körülbelül egy évvel a Petadev alapítója társalapítóként csatlakozott a céghez, azóta a rendszert üzemeltetjük és fejlesztjük tovább.
Az alkalmazást az Ostva referenciaoldalán mutatjuk be. Arról, hogyan választott fejlesztőcsapatot az amerikai alapító, egy angol nyelvű esettanulmányban írtunk.
Saját piactérben gondolkodsz?
Mondd el, kik között jönne létre az ügylet, mit lehetne foglalni vagy megrendelni és hogyan kezelnéd a fizetést. Ebből kiindulva átbeszéljük az első verzió működését, a szükséges integrációkat és a fejlesztési feladatokat.
