Mikor jó választás a widget?​

A widget egy előre megépített felület, amit egyetlen script taggal illeszthetsz be. Nincs szükség sem saját frontend fejlesztésre, sem backend módosításra.

Amire szükséged lesz:

1. Érvényes Komashi API-kulcs
2. Script tagot betölteni képes weboldal
3. data-key és data-mode attribútum beállítása

A widget automatikusan kezeli a szolgáltatáslista megjelenítését, az előfizetési folyamatot és a Komashi API-val való kommunikációt.

Mikor éri meg az API-t választani?​

Az API-val programozottan éred el és módosítod a Komashi adatait — providereket, szolgáltatásokat, ügyfeleket, előfizetéseket és számlákat. Minden kérést egy Bearer token azonosít.

Az API akkor a jobb út, ha:

• saját, egyedi felhasználói felületet építesz
• meglévő ügyfélportálhoz vagy belső dashboardhoz kell csatlakoztatnod a Komashit
• webhookokkal kombinálva valós idejű szinkronizációra van szükséged egy másik rendszerrel

→ API dokumentáció

Fejlesztési idő és rugalmasság​

A widget percek alatt üzemel, de azt kapod, amit a widget kínál. Az API teljes kontrollt ad a megjelenés és a logika felett, cserébe saját hibakezelést és jogosultságkezelést igényel.

Kinek melyik való?​

• Gyors indítást keresel fejlesztői kapacitás nélkül → widget
• Saját brandeddel egyedi felhasználói élményt építesz → API
• CRM-hez vagy belső rendszerhez kötnéd a Komashit → API
• Csak meg akarod jeleníteni a szolgáltatásaidat a weboldaladon → widget

A két megoldás nem zárja ki egymást. Sok provider widgettel indul, majd később API-integrációra vált, ahogy a rendszere összetettebbé válik.

Ha már van egy futó weboldalad vagy webalkalmazásod, a Komashi kétféle módon illeszthető bele: egy beágyazható widgettel vagy a REST API-n keresztül. A két megközelítés más fejlesztői tudást és eltérő mértékű munkát igényel, de mindkettő ugyanazt a célt szolgálja: az előfizetési és vásárlási folyamat megjelenítését a saját felületeden belül.

Ez az útmutató bemutatja, mikor melyik opciót érdemes választani, mit kell tudni mindkettőről, és hogyan indulhatsz el néhány lépésben.

Miért érdemes beágyazni, ahelyett hogy átirányítanád?​

A Komashi alapból tartalmaz egy white-label storefrontot, amelyre a végfelhasználókat egyszerűen átirányíthatod. Ez sok esetben teljesen elegendő — külön fejlesztés nélkül is működőképes vásárlási élményt ad.

Mégis van két helyzet, amikor a közvetlen integráció valódi értéket hoz:

Egységes ügyfélélmény. Egy átirányítás megszakítja a vásárlási folyamatot és kilép a saját brandedből. Ha azt szeretnéd, hogy a felhasználó végig a te felületeden maradjon — különösen, ha prémium ügyfélélménnyel dolgozol —, a widget vagy az API az út.

Saját rendszer összekötése. Ha meglévő ügyfélportálhoz, belső dashboardhoz vagy egyedi üzleti logikához kell csatlakoztatni a Komashit, az API-integráció ad valódi kontrollt. Webhookokkal kombinálva valós idejű szinkronizációt is megvalósíthatsz.

Két megközelítés: widget és API​

Widget: gyors beágyazás, minimális fejlesztéssel​

A Komashi widget egy előre megépített UI-komponens. Beillesztése egyetlen script tag elhelyezéséből áll — nincs szükség saját frontend megépítésére, és backend módosítást sem igényel.

A widget automatikusan kezeli:

• a szolgáltatáslista megjelenítését,
• az előfizetési folyamatot,
• a reszponzív elrendezést mobil és asztali nézetben egyaránt,
• a Komashi API-val való kommunikációt.

Konfiguráció: a widget viselkedése néhány data- attribútummal testre szabható.

Mikor válaszd? Ha gyorsan, minimális fejlesztési erőforrással szeretnéd megjeleníteni az előfizetési lehetőségeket. A widget arra van kialakítva, hogy néhány percen belül üzemelő állapotba lehessen hozni — különösen hasznos, ha nincs dedikált fejlesztői csapatod, de mégis integrált élményt szeretnél adni az ügyfeleidnek.

Amire szükséged lesz:

• érvényes Komashi API-kulcs
• script taget betölteni képes weboldal
• backend oldali változtatás nem szükséges

API: teljes kontroll, saját frontend​

A Komashi REST API-n keresztül programozottan kérdezheted le és módosíthatod a platform adatait. Minden kérést egy Bearer token azonosít, amelyet az Authorization fejlécben kell megadni.

Az API legfontosabb endpointjai:

A válaszok JSON formátumban érkeznek. Sikeres kérésnél data mező, hiba esetén error mező és HTTP státuszkód érkezik. Rate limit túllépésnél 429-es választ kapsz — ilyenkor exponenciális visszalépéssel érdemes újrapróbálkozni.

Mikor válaszd? Ha saját UI-t építesz, meglévő ügyfélrendszerbe integrálsz, vagy olyan egyedi logikát valósítasz meg, amit a widget önmagában nem fed le. Az API-t érdemes választani akkor is, ha CRM-hez vagy belső riportinghoz kell a Komashi adatokat szinkronizálni.

Amire szükséged lesz:

• Komashi API-kulcs a megfelelő jogosultságokkal
• backend vagy frontend kliens az API hívások kezeléséhez
• hibakezelési és rate limit logika

Hogyan működik ez a Komashi szemszögéből?​

Mindkét integráció API-kulcson alapul. A kulcsot a Komashi admin dashboardon lehet generálni a Beállítások → API szekciójában.

Kulcs létrehozásakor meg kell adni a nevet és a hozzárendelt jogosultságokat: olvasás, létrehozás, szerkesztés, törlés. A legkisebb szükséges jogosultság elvét érdemes követni: ha az integráció csak adatot olvas, törlési jogot ne kapjon. Ez csökkenti a kockázatot abban az esetben, ha a kulcs illetéktelen kézbe kerül.

Fontos: az API-kulcs értéke csak egyszer jelenik meg a generálás után. Azonnal mentsd el biztonságos helyre — a rendszer többet nem mutatja meg.

Tipikus hibák, amikre figyelj​

Widget esetén:

• Hiányzó data-mode attribútum: a widget nem jelenik meg megfelelően, ha a megjelenítési mód nincs megadva.
• Érvénytelen API-kulcs: a widget csendben nem tölt be, hibára nem feltétlenül figyelmeztet.
• HTTP környezet: a widget HTTPS kapcsolatot vár. HTTP-n kiszolgált oldalon nem fog megfelelően működni.

API esetén:

• Túl széles jogosultságok: Create + Delete jog egy olvasó integrációhoz szükségtelen kockázat.
• Nem kezelt 429-es válasz: burst forgalomnál rate limit hibák jelenhetnek meg. Tervezz be újrapróbálkozási logikát.
• Feltételezett válaszstruktúra: ne feltételezd, hogy minden válasz data mezővel érkezik — mindig vizsgáld meg az error mezőt is.

Lépésről lépésre​

1. Generálj API-kulcsot a Komashi dashboardban (Beállítások → API → Új API-kulcs).
2. Add meg a szükséges jogosultságokat — csak annyit, amennyit az integráció tényleg igényel.
3. Döntsd el, hogy widget vagy direkt API-integráció illik a projektedhez.
4. Widget esetén: illeszd be a script taget, add meg a data-key és data-mode attribútumokat, és teszteld a böngészőben.
5. API esetén: kezdd a /providers endpointtal, nézd meg a visszakapott JSON struktúrát, és épülj rá a saját UI-d.
6. Tesztelj sandbox környezetben mielőtt élesbe állsz.
7. Monitorozd az API hívásokat és a widget betöltési hibákat az első éles deploymentet követően.

Összefoglaló​

A Komashi mindkét esetben kezeli a fizetési folyamatot, az előfizetési logikát és a számlázást — neked csak az adatok megjelenítéséről vagy a saját rendszered összekötéséről kell gondoskodnod.

A részletes technikai leírást, az elérhető konfigurációs opciókat és a teljes endpoint dokumentációt ebben a cikkben találod.

How it works — step by step​

Provider side:

1. Enable the QR system in Settings → QR Code Settings (one toggle)
2. When a member arrives, open your phone camera or any QR reader
3. Point it at the customer's screen
4. The system shows the subscription status immediately: ✅ Active or ❌ Expired

End user side:

1. Open your subscription in the Komashi customer portal
2. Tap ... next to the subscription
3. Select QR Code Entry System
4. Show the QR code on your screen to the staff

Manual scanning vs automatic entry​

Manual scanning A staff member scans the QR code with any smartphone. No dedicated hardware needed. The screen immediately shows whether the subscription is valid. This is the simplest setup — no integration required.

Automatic entry via API With the Komashi API, the scan result can be processed automatically. This means the door, turnstile, or barrier opens without any manual step. The member walks in, the system handles the rest.

→ API documentation

Why it's faster​

Without QR access, every entry requires a name lookup, a manual check, or a member card. With QR:

• No searching for the customer in a list
• No checking if a membership is still active
• No delays at the door during busy hours
• Staff can focus on the member, not the screen

The result: shorter queues, smoother entries, and a better first impression every time a member arrives.

Who it's for​

• Gyms managing active memberships
• Fitness studios with class-based or unlimited plans
• Coworking spaces with day passes or monthly access
• Clubs and communities with member-only spaces
• Any physical business where subscription = access

Az előfizetéshez nem csak fizetés kell. Kell hozzá billing logika, számlázás, ügyfélkezelés, hozzáférési szabályok és egy vásárlási folyamat, amit az ügyfelek elsőre megértenek.

Ha mindent saját rendszerben akarsz megoldani, ezek a kérdések rögtön felmerülnek:

• Hogyan mennek az ismétlődő terhelések?
• Hogyan készülnek a számlák?
• Mi történik sikertelen fizetéskor?
• Hogyan kezeled a csomagváltást?
• Hogyan mondható le a szolgáltatás?

Ez mind időt, energiát és pénzt visz el attól, ami induláskor a legfontosabb: hogy legyen egy jó ajánlatod, amit a piac valóban meg akar venni.

Mi az előfizetéses modell valódi előnye?​

Kiszámíthatóbb bevétel, stabilabb cash flow, hosszabb ügyfélkapcsolatok. De ehhez a működésnek is stabilnak kell lennie.

Az előfizetés egyszerre érinti:

• az ajánlat csomagolását
• a billinget és invoicinget
• a hozzáférési logikát
• az ügyfélkommunikációt
• a branded élményt

Ha ezek külön rendszerekben élnek, gyorsan megnő a kézi munka és a hibázási lehetőség.

Hogyan néz ki egy tipikus indulás?​

1. Létrehozod a szolgáltatást
2. Beállítod az árazást — havi, éves vagy egyszeri opciókkal
3. Összekötöd a payment és invoicing oldalt
4. Beállítod a storefrontot
5. Egy helyen kezeled az ügyfeleket és az előfizetéseket

Az árazás nem szakad le a billingről, az ügyféladatok nem vesznek el külön rendszerben, és az értékesítési folyamat sem kézi workaroundokból áll.

A leggyakoribb hiba​

Indulás előtt a jövő összes edge case-ét akarni megoldani: több márka, speciális kedvezmények, bonyolult hozzáférési szabályok. Ezek egy része később valós igénnyé válhat — de induláskor csak lassítják a piacra lépést.

A jobb sorrend:

1. Tiszta ajánlat kialakítása
2. Meglévő subscription workflow használata
3. Billing és invoicing korai összekötése
4. Branded storefront indítása
5. Finomítás valós ügyfélviselkedés alapján

→ Első lépések a Komashin

Egy jól beállított storefront nem csak szebb, hanem működésileg is tisztább. Segít érthetően bemutatni a szolgáltatásokat, a csomagokat, az árakat és azt is, hogy pontosan mi történik a vásárlás után.

Miért fontos ez?​

Az előfizetés mindig egy folyamatos kapcsolat ígérete. Ha a felület bizonytalan, túl általános vagy zavaros, akkor a látogató nem csak a csomagban fog kételkedni, hanem a szolgáltató megbízhatóságában is.

A white-label storefront ezt a súrlódást csökkenti. A provider neve, vizuális megjelenése és ajánlati struktúrája egységes képet ad. Ez különösen fontos olyan szolgáltatásoknál, ahol a bizalom és a márka sokat számít.

Hogyan működik ez a Komashi szemszögéből?​

A Komashi storefront logikája nem különálló marketingoldalként működik, hanem a szolgáltatás, árazás, billing és ügyfélkezelés részeként. Ez azért erős, mert a publikus ajánlat és a háttérfolyamat nem csúszik szét.

Egy gyakorlati beállítás általában ezekkel indul:

• provider név
• logó és színpaletta
• subdomain vagy branded oldalstruktúra
• szolgáltatásdefiníciók
• pricing opciók

Ha ezek összhangban vannak, a storefront sokkal tisztábban kommunikál. A látogató gyorsabban érti meg, mit kínálsz, melyik csomag való neki, és milyen előfizetéses kapcsolatra számíthat.

Mire kell figyelni beállításkor vagy döntéskor?​

Az elsődleges szempont a tisztaság, nem a díszítés. Egy storefrontnak gyorsan válaszolnia kell néhány alap kérdésre:

• mit árulsz
• kinek szól
• mennyibe kerül
• mi történik vásárlás után

Ha ezt nem tudja pár másodperc alatt átadni, akkor túl bonyolult.

A második szempont a következetes branding. A provider név, logó és színvilág ne csak dekoráció legyen, hanem a bizalom része. Új vagy kevésbé ismert szolgáltatóknál ez különösen fontos.

A harmadik szempont az operatív megfelelés. A storefront tükrözze a valós szolgáltatáslogikát. Ha van havi és éves opció, az látszódjon tisztán. Ha van usage limit vagy hozzáférési feltétel, az legyen világos még a vásárlás előtt.

Kinek ideális ez a megoldás?​

Különösen hasznos:

• SaaS vállalkozásoknak előfizetéses hozzáféréssel
• stúdióknak és edzőtermeknek membership ajánlatokkal
• coworking szolgáltatóknak recurring csomagokkal
• olyan márkáknak, ahol a public sales flow része a bizalomépítésnek
• több csomagot vagy több ajánlatot kezelő providereknek

Ha branded előfizetéses vásárlási élményt akarsz építeni, alakítsd úgy a felületet, hogy az értékesítési logika és a működés egy irányba mutasson.

Miért érdemes az előfizetéses modellt választani?​

Az előfizetés nem csak egy árazási forma. Megváltoztatja, hogyan működik a vállalkozásod.

Kiszámítható bevétel minden hónapban Az egyszeri díjas modellben minden hónapban elölről kell kezdeni az értékesítést. Az előfizetésnél a meglévő ügyfeleid automatikusan fizetnek tovább. Nem kell minden hónapban meggyőzni őket újra.

Kevesebb adminisztráció Nincs kézi számlázás, nincs fizetéskövetés, nincs emlékeztető. Az előfizetés megújul, a számla kimegy, a hozzáférés megmarad – automatikusan.

Magasabb ügyfél lifetime value Egy ügyfél, aki havonta fizet, egy év alatt sokkal többet hoz, mint aki egyszer vásárol. Az előfizetés lehetőséget ad arra, hogy hosszabb távon is értéket adj – és kapj.

Alacsonyabb belépési küszöb az ügyfélnek Egy kisebb havi összeg könnyebben elfogadható, mint egy nagy egyszeri díj. Több ügyfél tud így elkezdeni, akik később visszatérnek.

Jobb tervezhetőség Ha tudod, hogy a következő hónapban kb. mennyi bevételed lesz, könnyebb dönteni: mikor veszel fel embert, mikor fektetsz be fejlesztésbe, mikor indítasz új ajánlatot.

Mikor működik az előfizetéses modell jól?​

Az előfizetés akkor természetes, ha a vevő folyamatos értéket kap:

• digitális hozzáférést (tartalom, szoftver, eszköz)
• havi coworking használatot
• membership előnyöket
• rendszeres támogatást vagy coachingot
• ismétlődő fizikai szolgáltatást (pl. heti edzés, havi takarítás)

Ha az ügyfél rendszeresen visszajön, vagy folyamatosan használja amit kínálsz, az előfizetés általában a természetesebb modell.

Mikor jobb az egyszeri díj?​

Az egyszeri díj akkor erős, ha a szolgáltatás diszkrét és lezárható:

• beállítási vagy onboarding szolgáltatás
• workshop vagy esemény
• konzultáció
• egyszeri implementáció vagy deliverable

Ha a vevő egyszer megkapja amit akar és nincs tovább szüksége a kapcsolatra, az egyszeri díj tisztább és egyszerűbb élményt ad.

Hogyan működik ez a Komashi szemszögéből?​

A Komashi támogatja a recurring és az egyszeri szolgáltatáslogikát is. Ez azért fontos, mert sok vállalkozás nem fér bele tisztán egyetlen árazási modellbe.

Van, ami természeténél fogva előfizetéses. Van, ami egyszeri fizetéssel működik jobban. És van, ahol a kettő együtt a jó megoldás – például egy belépő egyszeri ajánlat mellé havi tagság.

Mire kell figyelni döntés előtt?​

Hogyan fogyasztják a szolgáltatásodat? Ha a vevő rendszeres hozzáférést, ismétlődő támogatást vagy folyamatos jogosultságot kap, az előfizetés általában természetesebb. Ha egyetlen konkrét feladatot old meg a szolgáltatás, az egyszeri díj lehet a jobb irány.

Mi a megtartási kockázat? Az előfizetés kiszámíthatóbb bevételt hozhat, de folyamatos ígéretet is jelent. Ha nincs mögötte látható, ismétlődő érték, gyorsan nőhet a churn.

Mit preferálnak az ügyfeleid? Van, aki a kisebb havi terhet kedveli, mert könnyebb belépni. Más inkább egyszer fizet, mert átláthatóbbnak érzi. Érdemes ismerni a célközönséged döntési logikáját.

Kinek melyik modell való?​

Előfizetéses modell jellemzően jobb:

• membership üzleteknek
• ismétlődő digitális szolgáltatásoknak
• folyamatos hozzáférést adó termékeknek
• rendszeres használatra épülő szolgáltatásoknak

Egyszeri díj gyakran jobb:

• fix scope-os szolgáltatásoknak
• belépő ajánlatoknak
• egyszeri deliverable-eknek
• projektalapú vagy eseményalapú munkáknak

Hibrid modell különösen jól működhet ott, ahol van egy visszatérő alapajánlat mellette opcionális egyszeri extra szolgáltatással.

Ha most alakítod ki a szolgáltatásod árazását, gondold át a Komashi pricing és service setup szempontjait, hogy a modell ne csak jól hangozzon, hanem operatívan is jól működjön.

A billing periódus hat a belépési küszöbre, az ügyfél elköteleződésére, a cash flow-ra és a megtartásra is. Ha jól van kialakítva, erősíti a bevétel stabilitását. Ha rosszul, akkor összezavarja a vevőt és ronthatja a marginokat.

Miért fontos ez?​

Az éves csomag legnagyobb előnye jellemzően a kiszámíthatóság. Előbb hoz be pénzt, és csökkenti a rövid távú lemorzsolódás esélyét. A havi csomag előnye inkább a könnyebb belépés: kisebb az elköteleződés, könnyebb kipróbálni.

Ez a tradeoff akkor működik jól, ha a szolgáltatásod értékátadása is ezt támogatja. Nem mindegy ugyanis, hogy digitális hozzáférésről, korlátozott használatról, személyes szolgáltatásról vagy membership alapú modellről beszélünk.

Hogyan működik ez a Komashi szemszögéből?​

A Komashi service és pricing struktúrája segít abban, hogy a havi és éves csomagok ne csak árként jelenjenek meg, hanem üzleti logikaként is. Előbb definiálod a szolgáltatást, utána azt, hogyan csomagolod és milyen periódusokkal értékesíted.

Például:

• egy havi gym membership rendszeres használatra épül
• egy éves csomag ugyanennek hosszabb elköteleződési változata lehet
• egy digitális szolgáltatásnál a havi és éves plan eltérő commitment szintet jelenthet

Ennek előnye, hogy a pricing, a billing és az ügyféladatok együtt kezelhetők, így könnyebb átlátni, melyik terv hogyan teljesít.

Mire kell figyelni beállításkor vagy döntéskor?​

Először tedd fel a kérdést: miért létezik mindkét csomag? Ha csak azért, mert másoknál is láttad, az gyenge kiindulópont.

A havi csomag általában akkor jó, ha:

• alacsony belépési küszöb kell
• a vevő először kipróbálná a szolgáltatást
• szélesebb top-of-funnel a cél

Az éves csomag akkor működik jól, ha:

• az értékajánlat már világos
• a vevő hosszabb távú előnyt kap
• fontosabb a bevétel kiszámíthatósága

Ezután jön az éves kedvezmény kérdése. A diszkontnak érezhetőnek kell lennie, de nem eheti meg a marginodat. Ha a szolgáltatás teljesítése költséges, túl nagy engedményt adni könnyen rossz döntés lehet.

Kinek ideális ez a megoldás?​

Ez a téma leginkább azoknak fontos, akiknek van ismétlődő értékajánlatuk:

• SaaS szolgáltatóknak
• stúdióknak és membership üzleteknek
• coworking szolgáltatóknak
• digitális oktatási termékeknek
• recurring alapú szolgáltató márkáknak

Ha több billing periódussal tervezel, gondold át a Komashi pricing és szolgáltatáskezelési szempontjait, és csak utána véglegesítsd a csomagstruktúrát.