Marketplace nėra katalogas su mokėjimo mygtuku. Tai pasitikėjimo ir sandorių sistema, kurioje skirtingi dalyviai turi skirtingas teises, pinigai juda keliomis kryptimis, o beveik kiekvienas veiksmas gali nepavykti. Brangiausios klaidos atsiranda tada, kai pirmiausia kuriamas gražus UI, o sandorio modelis paliekamas vėlesniam etapui.
Prieš pirmą sprintą turi būti aišku
- Kas yra sandoris ir kada jis laikomas baigtu?
- Kas kuriuo momentu valdo pinigus ir atsakomybę?
- Kokias teises turi kiekviena rolė?
- Kas vyksta atšaukimo, grąžinimo, ginčo ar tiekėjo gedimo atveju?
1. Nupieškite sandorio būsenų mašiną
Pradėkite ne nuo puslapių, o nuo vieno sandorio gyvenimo ciklo. Pavyzdžiui: juodraštis → rezervuota → apmokėta → paslauga pradėta → įvykdyta → išmoka atlikta. Šalia turi egzistuoti nesėkmės šakos: atmesta, baigėsi laikas, atšaukta, grąžinta, ginčas.
Kiekvienam perėjimui užrašykite, kas jį gali inicijuoti, kokios sąlygos būtinos ir koks nekintamas įvykio įrašas paliekamas. Taip būsena tampa verslo taisykle, o ne atsitiktiniu lauku duomenų bazėje.
- Viena aiški pagrindinė sandorio būsena
- Atskira mokėjimo ir išmokos būsena
- Idempotentiški veiksmai pakartotiniams webhookams
- Laiko limitai ir automatiniai perėjimai
- Pilna įvykių istorija ginčams ir auditui
2. Sukurkite rolių ir teisių matricą
Pirkėjas, pardavėjas, organizacijos administratorius, palaikymo specialistas ir sistemos administratorius mato skirtingus duomenis ir atlieka skirtingus veiksmus. Vien tik frontendo mygtuko paslėpimas nėra prieigos kontrolė.
Matricą kurkite pagal objektą ir veiksmą: kas gali peržiūrėti užsakymą, keisti kainą, matyti asmens duomenis, inicijuoti grąžinimą ar atlikti išmoką. Tikrinimas turi vykti serveryje, o jautrūs administratoriaus veiksmai — būti audituojami.
- Rolė ir organizacinis kontekstas
- Objektas ir konkretus veiksmas
- Duomenų laukai, kuriuos rolė gali matyti
- Keturių akių principas finansiniams veiksmams
- Laikinos palaikymo komandos prieigos
3. Atskirkite užsakymą, mokėjimą ir apskaitos žurnalą
Užsakymo būsena nėra banko tiesa. Mokėjimo paslaugų teikėjas gali vėluoti, webhookas gali pasikartoti, kortelės mokėjimas gali būti užginčytas po kelių savaičių. Todėl verslo sandoris, mokėjimo bandymai ir vidinis finansinių įvykių žurnalas turi būti atskiri modeliai.
Nekeičiamas žurnalas leidžia atsakyti, kodėl balansas yra būtent toks. Jame registruojami autorizavimai, mokesčiai, komisiniai, grąžinimai, išmokos ir korekcijos. Balansas apskaičiuojamas iš įvykių, o ne taisomas rankiniu skaičiumi.
- Mokėjimo bandymas turi unikalų idempotency raktą
- Webhookas tikrinamas ir apdorojamas pakartotinai saugiai
- Komisiniai ir mokesčiai registruojami atskirai
- Grąžinimas nesunaikina pradinio įvykio
- Kasdienis suderinimas su mokėjimų tiekėju
4. Pasitikėjimas yra produkto funkcija
KYC, reitingai ir moderavimas nėra tik compliance priedai. Jie tiesiogiai veikia konversiją ir saugumą. Svarbu apibrėžti, kokio pasitikėjimo lygio reikia prieš skelbimą, rezervaciją, mokėjimą ir išmoką.
Riziką valdykite sluoksniais: tapatybės signalai, elgsenos taisyklės, limitai naujiems dalyviams, žmogaus peržiūra ir aiškus apeliacijos procesas. Per griežta patikra nužudo pasiūlą; per laisva — platformos reputaciją.
- Proporcingas tapatybės patikrinimas
- Aiškūs naujo pardavėjo limitai
- Reitingai tik po tikro sandorio
- Pranešimų ir turinio moderavimo kelias
- Ginčo įrodymai vienoje laiko juostoje
5. Paleiskite siaurą branduolį, ne pusę ekosistemos
Pirmoje versijoje rinkitės vieną geografiją, vieną pagrindinę sandorio rūšį ir kuo mažiau kainodaros išimčių. Rankinis operacinis žingsnis pradžioje yra priimtinas, jei jis matomas, išmatuotas ir turi aiškų automatizavimo slenkstį.
Stebėkite ne tik registracijas. Marketplace sveikatą parodo likvidumas: kiek paklausos randa tinkamą pasiūlą, per kiek laiko įvyksta sandoris, kiek jo etapų žlunga ir kiek kainuoja išspręsti išimtį.
- Paieškos iki kontakto konversija
- Kontakto iki apmokėto sandorio konversija
- Laikas iki pirmo atsakymo ir sandorio
- Atšaukimų, grąžinimų ir ginčų dalis
- Pasiūlos aktyvumas ir pakartotiniai sandoriai
- Operacinis laikas vienam sandoriui
Naudokite savo komandoje
Marketplace branduolio patikra
Pažymėkite punktą tik tada, kai turite konkretų įrodymą — dokumentą, metriką, demonstraciją ar atsakingo žmogaus patvirtintą procesą.
- 01Apibrėžta viena pagrindinė vertės ir pinigų tėkmė
- 02Sandorio būsenos turi sėkmės ir nesėkmės šakas
- 03Būsenų perėjimai palieka įvykių istoriją
- 04Rolės ir teisės tikrinamos serveryje
- 05Jautrūs administratoriaus veiksmai audituojami
- 06Užsakymas atskirtas nuo mokėjimo bandymų
- 07Webhookai apdorojami idempotentiškai
- 08Finansiniai įvykiai nekintami
- 09Balansas suderinamas su mokėjimų tiekėju
- 10Grąžinimo ir ginčo procesas išbandytas
- 11KYC reikalavimai susieti su rizika
- 12Reitingą gali palikti tik sandorio dalyvis
- 13Nustatyti limitai naujiems dalyviams
- 14Asmens duomenys nerodomi be poreikio
- 15Yra tiekėjo gedimo scenarijus
- 16Svarbiausios funnel metrikos matuojamos
- 17Operacinės išimtys turi savininką
- 18Pirmo paleidimo apimtis sąmoningai siaura
FAQ
Dažniausi klausimai
Kiek kainuoja sukurti marketplace platformą?+
Kainą labiausiai lemia ne ekranų skaičius, o sandorio sudėtingumas: rolės, mokėjimų ir išmokų modelis, KYC, ginčai, mobiliosios programėlės bei integracijos. Tikslinga pirmiausia investuoti į 1–2 savaičių architektūros etapą ir tik tada vertinti įgyvendinimą.
Ar pradžiai tinka no-code marketplace?+
Tinka, jei sandoris paprastas, mokėjimai nevyksta per platformą ir svarbiausia patikrinti paklausą. Kai reikia sudėtingų rolių, išmokų, KYC ar individualios rizikos logikos, no-code ribos atsiranda greitai.
Kada integruoti KYC?+
Ne automatiškai registracijos metu. Patikrą verta aktyvuoti prieš veiksmą, kuris sukuria realią riziką—pavyzdžiui, skelbimo publikavimą, didesnį limitą ar pirmą išmoką—atsižvelgiant į verslo ir teisinius reikalavimus.
Ar platforma turėtų pati laikyti klientų pinigus?+
Dažniausiai saugiau remtis licencijuotu marketplace mokėjimų paslaugų teikėju ir jo sąskaitų bei išmokų modeliu. Konkretų sprendimą būtina suderinti su mokėjimų ir teisės specialistais.
Pirminiai šaltiniai
Tolimesniam techniniam gilinimuisi:
Stripe Connect documentation