Előfizetéses rendszer: saját fejlesztés vagy kész megoldás?

Röviden

Ha azon gondolkodsz, hogy saját előfizetéses rendszert fejlessz vagy kész megoldást válassz, ne egyben dönts, hanem követelményenként. Ami a szolgáltatásodat megkülönbözteti (hozzáférés, saját alkalmazás), azt építsd meg magad; ami minden előfizetésnél ugyanaz (megújítás, csomagváltás, lemondás, számlázás, áfa, ügyfélportál), azt érdemes kész rendszerből venni. A cikk pontozható mátrixa és letölthető munkalapja megmutatja, mi marad nálad.

Röviden: saját fejlesztés vagy kész megoldás?

Ha azon gondolkodsz, hogy saját előfizetéses rendszert fejlessz vagy kész megoldást válassz, ne egyetlen igen/nem kérdésként kezeld a döntést. Bontsd követelményekre, és mindegyiknél két dolgot nézz meg: megkülönbözteti-e a szolgáltatásodat, és mekkora üzemeltetési teher, ha te viszed.

A legtöbb szolgáltatónál a két csoport jól elválik:

• Egyedi nálad: mit kap az ügyfél és mikor, hogyan működik a saját alkalmazásod, milyen szabály dönt a hozzáférésről, mit mérsz felhasználásként.
• Minden előfizetésnél ugyanaz: csomagok és számlázási időszakok, vásárlás, megújítás, csomagváltás, lemondás, számlakiállítás, áfa országonként, ügyfélportál, csapatjogosultságok.

Az első csoportot érdemes magadnál tartani, a másodikat kész rendszerből venni. Saját fejlesztés akkor indokolt, ha a második csoport valamelyik eleme nálad mégsem szokványos, és ez üzleti előnyt ad. Ezt alább egy pontozható mátrixszal és három szemléltető példával lehet eldönteni. Ha sietsz, ugorj egyenesen a követelmény- és felelősségi mátrixhoz, vagy töltsd le a munkalapot Excelben.

Hogyan néz ki a kész megoldás a Komashival?

Ha a kész megoldás felé hajlasz, a Komashiban az indulás három lépés:

1. Szolgáltató létrehozása. Leírod a vállalkozásodat, a Komashi létrehozza a saját márkás munkaterületedet és az első szolgáltatásodat. A generált csomagokat és árakat át kell nézned.
2. Beállítás. A Vezérlőközpont beállítási listájában megadod a Komashi díjaihoz a bankkártyát, a számlázási adataidat és a jogi linkjeidet, majd bekapcsolod a fizetési módokat a saját fizetési szolgáltatódon. Számlázót opcionálisan köthetsz be.
3. Értékesítés és követés. Megosztod a szolgáltatói oldalad linkjét, vagy beágyazod a widgetet a weboldaladba; az előfizetéseket, csomagváltásokat és számlákat a Vezérlőközpontban követed.

A részletes lépéseket a Komashi indulási útmutatója írja le, a folyamat áttekintését pedig az Így működik a Komashi oldal adja.

Ha még csak most indítod el az első előfizetéses szolgáltatásodat, előbb nézd át az előfizetéses rendszer saját weboldalon induló checklistjét.

Mi valóban egyedi a te szolgáltatásodban?

Fejlesztői szemmel az előfizetés egy táblának tűnik: ügyfél, csomag, ár, következő terhelés dátuma. Ez az első hét munkája. Utána jönnek azok a kérdések, amelyek nem a terméked különlegességéből fakadnak, hanem abból, hogy pénzt szedsz be ismétlődően:

• Mi történik, ha az ügyfél a hónap közepén nagyobb csomagra vált (felminősítés)? Mennyit fizet ma, és mennyit a következő megújításkor?
• Mi történik, ha kisebb csomagra vált (leminősítés)? Visszatérítesz, vagy az időszak végén lép életbe?
• A lemondás azonnal megszünteti a hozzáférést, vagy az időszak végéig marad?
• Ki állítja ki a számlát, és mikor? Mi a helyzet az ingyenes csomaggal, ahol nincs mit kifizetni?
• Céges ügyfélnél ellenőrzött adószám alapján más az áfa, mint magánszemélynél. Melyik országból lehet egyáltalán vásárolni?
• Ki láthatja a csapatodból az ügyfeleket, és ki adhat kedvezményt?

Ezekre a kérdésekre van jó válasz, csak nem a te üzleti előnyöd. Ha a szolgáltatásod egy könyvelési tanácsadói csomag, egy online tanfolyam vagy egy szoftver, az ügyfeled nem azért választ téged, mert a csomagváltás arányosítása különösen elegáns. Viszont azonnal észreveszi, ha hibás.

A jó kérdés tehát nem az, hogy „meg tudjuk-e írni”, hanem: melyik követelményért vállalsz szívesen évekig felelősséget?

Mit kell üzemeltetni, ha magad építed?

A saját rendszer valódi költsége nem az induláskor, hanem az évek során jelentkezik. Egy saját előfizetéskezelő rendszer folyamatosan fut, és minden megújításkor, minden csomagváltáskor és minden szabályváltozáskor újra bizonyítania kell. Ha magad építed, ezek mind a te csapatodnál maradnak:

Terület	Amit üzemeltetni kell
Katalógus	Szolgáltatás, csomag, számlázási időszak, kiegészítők, kedvezmények; az árváltozás ne írja át a meglévő előfizetéseket
Vásárlás	Fizetési oldal, fizetési szolgáltató bekötése, visszatérés a fizetésből, sikertelen fizetés kezelése
Életciklus	Megújítás, felminősítés arányos díjjal, leminősítés ütemezése, lemondás, szolgáltatás törlésének hatása az előfizetőkre
Számlázás	Számla minden sikeres fizetés után, ingyenes csomag kezelése, sztornó, számlaarchívum
Adó	Áfakulcsok, céges és magánügyfél eltérő kezelése, adószám-ellenőrzés, letiltott országok
Ügyféloldal	Belépés, előfizetések és számlák listája, számlázási adatok módosítása, lemondás
Csapat	Szerepkörök, ki adhat kedvezményt, ki láthatja az ügyféladatokat
Integráció	API, eseményértesítések, újrapróbálás, idempotens feldolgozás, naplózás

Ez nem érv a saját fejlesztés ellen. Azt mutatja meg, hogy a saját fejlesztésű előfizetés-kezelés nem projekt, hanem egy újabb termék, amelyet karban kell tartani.

Így osztja meg a feladatot a Komashi

Ha kész rendszert választasz, ugyanezek a területek nem tűnnek el, csak máshol dől el, ki viszi őket. A Komashi docs alapján a megosztás így néz ki:

• Pénz: az ügyfél a te fizetési szolgáltatódnak fizet, a kifizetés a te számládra érkezik; a Komashi nincs benne a pénzáramlásban. A fizetési módokat a fizetési szolgáltatók beállításánál kapcsolod be.
• Számla: a bekötött számlázási szolgáltató minden sikeres fizetés után automatikusan kiállítja. Fizetendő összeg nélküli vásárlásnál (ingyenes csomag, próbaidőszak indulása) a Komashi nem hívja meg a számlázót. A bekötés opcionális: kézzel is számlázhatsz. Az összefoglalót a fizetési és számlázási integrációk oldala adja.
• Csomagváltás (fel- és leminősítés): az előfizetések útmutatója szerint a felminősítésnél csak a különbözetet kell ma kifizetni, a hátralévő időszakra arányosítva; a leminősítés az időszak végén lép életbe, és nincs visszatérítés. A katalógusár módosítása nem változtatja meg a meglévő előfizetés árát.
• Lemondás és törlés: a szolgáltatói szabályokban döntöd el, hogy a lemondás az időszak végén vagy azonnal lép életbe, és hogy egy törölt szolgáltatás előfizetései lejárnak vagy tovább újulnak.
• Áfa: az árat nettóként adod meg; a felszámított áfa a vásárláskor dől el a szolgáltatás áfatípusa, a te és az ügyfél országa, valamint az alapján, hogy az ügyfél céges adószámmal vásárol-e. Országonként le is tilthatod a vásárlást (áfa- és adóprofilok). Ez beállítási lehetőség, nem adójogi megfelelőségi garancia: a saját szabályaidat érdemes szakemberrel ellenőriztetni.

Amit a kész rendszerrel vállalsz

A kész rendszernek is ára van, és ezt a döntés előtt érdemes kimondani:

• Az adatmodell keretei. Az ajánlatodnak bele kell férnie a szolgáltatás–csomag–időszak–kiegészítő–felhasználás szerkezetbe. Ami nem fér bele, ahhoz kerülőút vagy saját fejlesztés kell.
• Kötött szabályok. Az arányosítás, a leminősítés és a lemondás a rendszer szabályai szerint működik. Ha ezektől eltérő szabály kell, az a mátrixban E ≥ 2 sor.
• Korlátozott írási felület. A katalógust és a kuponokat a Vezérlőközpontban állítod be; a docs szerint nem minden katalóguselemhez van nyilvános REST írási végpont.
• Folyamatos díj és kilépés. A kész rendszer díja folyamatos költség. Induláskor nézd meg azt is, hogyan éred el az adataidat: a REST API-n az ügyfelek, előfizetések és számlák lekérdezhetők.

Egy dolgot külön ellenőrizz: a sikertelen ismétlődő fizetés újrapróbálásáról és a türelmi időről a Komashi docs jelenleg nem ír. Ha ez nálad kritikus, élesítés előtt kérdezd meg, és nézd meg a fizetési szolgáltatód beállításait is.

Követelmény- és felelősségi mátrix

Ez a cikk saját munkalapja. Minden sorhoz adj két pontszámot 0-tól 3-ig:

• E – egyediség: mennyire különbözteti meg a szolgáltatásodat ez a követelmény? (0: egyáltalán nem, 3: ez az üzleti előnyöd)
• T – üzemeltetési teher: mennyi folyamatos munkát és kockázatot jelent, ha magad viszed? (0: elhanyagolható, 3: hibája pénzbe vagy jogi kockázatba kerül)

Döntési szabály:

• E ≥ 2 és T ≤ 1: építsd meg magad, vagy a saját alkalmazásodban kezeld, egy kész rendszer API-jára támaszkodva.
• E ≥ 2 és T ≥ 2: csak akkor építsd meg, ha a folyamatos üzemeltetést is vállalod. Ha nem, szűkítsd az egyedi részt: ami valóban egyedi, maradjon nálad, a szokványos maradékot vedd kész rendszerből.
• E ≤ 1 és T ≥ 2: vedd kész rendszerből.
• E ≤ 1 és T ≤ 1: mindegy; abba a rendszerbe tedd, ahol a többi rokon adat van.

Követelmény	E	T	Ha te építed, a te feladatod	Komashival ki kezeli	Ami nálad marad
Csomagok, időszakok, árak			Adatmodell, árváltozás kezelése	Komashi katalógus	Az ajánlat tartalma és ára
Vásárlás és fizetési oldal			Fizetési oldal, szolgáltatói bekötés	Komashi vásárlási folyamat + a te fizetési szolgáltatód	Fizetési szolgáltató kiválasztása, szerződése
Megújítás			Ütemezés, terhelés, hibakezelés	Komashi + a te fizetési szolgáltatód	Sikertelen fizetés folyamatának ellenőrzése
Csomagváltás, arányosítás			Számítási szabály, ütemezett leminősítés	Komashi	Engedélyezed-e
Lemondás			Felület, szabály, hozzáférés vége	Komashi ügyfélportál	Lemondási mód kiválasztása, feltételeid
Számlakiállítás			Számlázó bekötése, sztornó	A bekötött számlázási szolgáltatód	Számlázó kiválasztása vagy kézi számlázás
Áfa és országok			Szabálymotor, adószám-ellenőrzés	Komashi áfaszabályok	Adóprofil és országszabályok beállítása, szakmai ellenőrzés
Ügyfélportál			Belépés, listák, adatmódosítás	Komashi ügyfélportál vagy widget	Márka, jogi linkek
Csapatjogosultság			Szerepkörök, naplózás	Komashi admin/operátor szerepkörök	Ki kap hozzáférést
Hozzáférés a szolgáltatáshoz			Hozzáférési szabály és ellenőrzés	–	A szolgáltatás nyújtása és a hozzáférési döntés
Felhasználásmérés			Mérés és elszámolás	Komashi felhasználási adat az előfizetésen	Mit mérsz, mikor küldöd
Saját alkalmazás szinkronja			Teljes egészében	REST API és webhookok	Fogadó végpont, idempotens feldolgozás

A két üres oszlopot te töltöd ki; ugyanaz a sor egy tanácsadónál és egy SaaS-csapatnál mást kap. Telefonon vagy csapatban egyszerűbb a letölthető munkalappal dolgozni: Excel (XLSX) vagy pontosvesszővel tagolt CSV. Táblázatkezelőben megnyitható, és a döntési szabályt is tartalmazza. Ha egy sorban E ≥ 2 és a Komashi adatmodellje (szolgáltatás, csomag, időszak, kiegészítő, felhasználás) nem írja le az igényt, az valódi érv a saját fejlesztés mellett annál a pontnál.

Három szemléltető döntés

Az alábbi csapatok kitalált példák a mátrix használatára, nem ügyfelek és nem mért eredmények.

1. Egyéni tanácsadó havi és éves csomaggal

Három csomag, havi és éves időszak, magánszemély és cég is vásárol. Nincs fejlesztő a csapatban.

• Magas E csak a tanácsadás tartalmánál van; minden számlázási sor E 0–1, T 2–3.
• Döntés: kész rendszer, fejlesztés nélkül. A szolgáltatói oldal (a Komashin futó nyilvános vásárlási oldalad, ahol az ügyfél a csomagjaid közül választ és fizet) vagy a weboldalba ágyazott widget elég; a fizetési és számlázási szolgáltató bekötése, a lemondási mód és az áfaszabályok beállítása a feladat.

2. Kis SaaS-csapat saját alkalmazással és felhasználási limittel

A saját alkalmazásban fut a szolgáltatás, a csomagok havi felhasználási kerettel működnek (a keret és a kiegészítők beállítását a használati limitek és kiegészítők oldala mutatja be).

• A hozzáférés és a felhasználásmérés E 3; a megújítás, számla, áfa és csomagváltás E 0–1.
• Döntés: vegyes megoldás: a számlázás kész rendszerben, a hozzáférés a saját alkalmazásban. A vásárlást a REST API indítja (POST /services/{service}/subscriptions, az ügyfelet a visszakapott checkout_url címre irányítod), a felhasználást sync-usage (új összérték) vagy adjust-usage (növelés/csökkentés) hívással küldöd. A hozzáférést a saját alkalmazás dönti el, az előfizetés Komashiban tárolt állapota alapján.

3. Szolgáltató ügyfelenként egyedi szerződéses elszámolással

Minden ügyfélnek más a díjszabása, a számlázás egyedi mérföldkövekhez kötött, és ez az ajánlat része.

• A számlázási logika itt E 3, és nem írható le csomaggal, időszakkal és kiegészítővel.
• Döntés: ez az E ≥ 2 és T ≥ 2 eset. Ennél a pontnál saját fejlesztés vagy egyedi számlázási folyamat indokolt, de csak akkor, ha a csapat a folyamatos üzemeltetést is vállalja. Ha a szolgáltatónak mellette szokványos előfizetéses csomagjai is vannak, azokat érdemes külön, kész rendszerben kezelni.

Mit fejlessz magad akkor is, ha kész rendszert választasz?

Ha a saját alkalmazásodat kötöd be, a kész rendszer nem vesz le minden fejlesztési feladatot. Ezek nálad maradnak:

1. API-kulcs csak a szerveren. A kulcsot az API-kulcsok oldalon hozod létre, a szükséges jogosultsággal: olvasáshoz elég az Olvasás, vásárlás indításához Létrehozás, felhasználás-frissítéshez és lemondáshoz Frissítés jog kell (angol felületen: Read, Create, Update). A widget beágyazásához nem kell API-kulcs a böngészőben.
2. Hozzáférés az állapotból, nem a visszatérési címből. Az, hogy a böngésző visszatért a return_url címre, még nem bizonyítja a fizetést. Fizetős hozzáférés előtt olvasd ki az előfizetés aktuális állapotát.
3. Webhookok ismétlésbiztosan. A webhookok HMAC-SHA256 aláírással érkeznek; ellenőrizd az eredeti kérés bájtjain. A docs szerint (2026. november) egy kézbesítésre összesen legfeljebb négy kísérlet jut, az újrapróbálások 10, 60 és 300 másodperc után indulnak; az aktuális értékeket mindig a docsban nézd meg. Ezért ugyanaz az esemény többször is megérkezhet, és a sorrendjük sem garantált. Válaszolj gyorsan 2xx kóddal, a lassú munkát végezd később, és fontos döntés előtt olvasd vissza az állapotot az API-n.
4. Óvatos újrapróbálás írásnál. Az adjust-usage minden ismétléskor újra alkalmazza a változást; hálózati hiba után előbb olvasd ki az aktuális értéket.

A végpontok és mezők pontos, mindig aktuális leírása az interaktív API-referenciában van. Ezt a Vezérlőközpont Integráció → API oldalán a Dokumentáció hivatkozás nyitja meg (lásd a REST API-integráció útmutatót). A cikk csak a döntéshez szükséges részt idézi. A widget, az API és a webhook együtt is használható; hogy melyik illik hozzád, a fejlesztői áttekintés foglalja össze.

Következő lépés

Töltsd ki a mátrixot a saját szolgáltatásodra (Excel). Ha a számlázás nem jelent versenyelőnyt, vagyis a legtöbb számlázási sor E 0–1, érdemes kész rendszerrel indulnod, és csak a saját alkalmazásod határát megépítened.

• Fejlesztés nélkül indulnál? Hozd létre a szolgáltatódat a Komashin. A szolgáltatói oldal és a widget kódírás nélkül működik; az első lépéseket az indulási útmutató mutatja.
• A saját alkalmazásodat kötnéd be? Nézd meg a Komashi fejlesztői oldalát (API, webhookok), majd folytasd a docs fejlesztői áttekintésével és egy csak Olvasás jogú API-kulccsal tett első kéréssel.

Gyakori kérdések

Mikor éri meg saját előfizetéses rendszert fejleszteni?

Akkor, ha maga a számlázási logika a szolgáltatásod megkülönböztető része, vagy ha az ajánlatod nem írható le szolgáltatás, csomag, számlázási időszak, kiegészítő és felhasználás egységeivel. Ilyenkor számolj azzal, hogy a megújítást, a csomagváltást, a lemondást, a számlázást és az áfát nem egyszer kell megírni, hanem folyamatosan üzemeltetni és karbantartani.

Kell fejlesztő a Komashi használatához?

Nem feltétlenül. A Komashi szolgáltatói oldala és a beágyazható widgetek fejlesztés nélkül is működnek. Fejlesztőre akkor van szükség, ha a saját alkalmazásodat kötöd be: REST API-val indítasz vásárlást, rögzítesz felhasználást, vagy webhookkal frissíted a saját hozzáférési szabályaidat.

Ki kezeli a pénzt, ha kész előfizetéses rendszert használok?

A Komashinál az ügyfél a te fizetési szolgáltatódnak fizet, és a kifizetés a te számládra érkezik; a Komashi nem vesz részt a pénzáramlásban. A fizetési szolgáltatót a Beállítások között kapcsolod be a saját hozzáférési adataiddal.

Kiállítja a Komashi a számlát az előfizetésről?

A számlát a bekötött számlázási szolgáltatód állítja ki automatikusan minden sikeres fizetés után. A bekötés opcionális: kézzel, a Komashin kívül is számlázhatsz, ilyenkor a számla a te felelősséged, a tranzakciót és az előfizetést a Komashi ettől még nyilvántartja.

Mi marad nálam, ha kész rendszert választok?

A szolgáltatás nyújtása és a hozzáférési döntés a saját alkalmazásodban. Ha integrálsz, a hozzáférést az előfizetés Komashiban tárolt állapota alapján add meg, ne a böngésző visszatérési címéből; a webhookokat aláírás-ellenőrzéssel és ismétlésbiztosan dolgozd fel; az API-kulcsot pedig csak a szervereden tárold.

Források és további olvasnivaló

• Komashi Docs — Első lépések
• Komashi Docs — Fejlesztői áttekintés
• Komashi Docs — REST API-integráció
• Komashi Docs — Webhookok
• Komashi Docs — API-kulcsok
• Komashi Docs — Widgetek beágyazása
• Komashi Docs — Előfizetések
• Komashi Docs — Szolgáltatói szabályok
• Komashi Docs — Fizetési szolgáltatók
• Komashi Docs — Számlázási szolgáltató
• Komashi Docs — Áfa- és adóprofilok
• Komashi Docs — Ki a szolgáltató?

Frissítve: 2026. november 9.