ugrás a tartalomhoz

Előfizetési rendszer implementációja

webproghu · 2014. Nov. 3. (H), 16.54
Sziasztok,

egy webes szolgáltatás előfizetési rendszerén dolgozom,
őszintén szólva még nem volt részem ilyen jellegű rendszer fejlesztésében,
így gondoltam létrehozok egy fórumtémát, hátha előkerülnek
hasznos tanácsok, ötletek, esetleg van valakinek nagyobb tapasztalata
egy ilyen rendszer implementációjában.

Az alapállapot a következő:
- a rendszerben vannak felhasználók (User), ők regisztrálhatnak, illetve igénybe vehetik a szolgáltatásokat
- vannak különböző csomagok (Plan), különböző árakkal, illetve limitációkkal (tárterület, stb)
- a csomagokra a felhasználók elő tudnak fizetni (Subscription), tudnak hónap közben csomagot váltani (nagyobb és kisebb csomagra is),
egy felhasználó egyszerre csak egy csomagra tud előfizetni
- a felhasználók havi vagy éves konstrukcióban is elő tudnak fizetni egy-egy csomagra, éves esetén kedvezményt kapnak a csomag árából
- minden hónap elején kiállításra kerül a felhasználó számára egy számla az aktuális hónapról (tehát előre fizet)


Első körben a következő kérdések merültek fel bennem:
- hogyan lehetne elegánsan megoldani az előfizetés alapján a számlák generálását? Éves előfizetés esetén évente, havi
előfizetés esetén havonta. A cron-os megoldás nem annyira tetszik (mi történik ha a számlák generálása közben meghal a cron job)
- hogyan kezelnétek a tört hónapokat? (január 12-én fizet elő az egyik csomagra a felhasználó)
- hogyan kezelnétek a csomagváltásokat? (kisebb csomagra váltáskor időarányosan fennmarad a csomag árából valamekkora összeg, nagyobb csomag váltsára esetén a
különbözetet ki kell számlázni)


Előre is köszönök minden segítséget, építő jellegű hozzászólást!
 
1

2 ev

janoszen · 2014. Nov. 3. (H), 19.22
Az elmult 2 evben ilyesmin dolgoztam. Eleg altalanos tema es nehez jol osszerakni, de megeri.

Ami az en tapasztalatom volt, hogy olyan adatot, ami alapjan nem akarsz keresni, azt lehet JSON-ban kodolva tarolni. Azert nem serialize(), mert akarhatsz mas platformmal is hozzaferni. Ennek az az elonye, hogy eltarolod, hogy melyik PHP osztalyod kezeli pl a lejaratot es az mar a JSON-ban tomoritett, specialis adatok alapjan dolgozik.

Pelda: elkezdodik egy elofizetes, jon a PHP osztaly, kiszamolja, mikor kell legkozelebb foglalkozni vele. Egy interface-t implemental, de akarhany modellt le tud kezelni, akarmilyen elcsettintett is. Alapvetoen mi ugy dolgozunk, hogy 30 napos vagy 365 napos idointervallumokkal dolgozunk, masnak csak akkor van ertelme, ha ugyfel igeny van ra (ez esetben napi elszamolas), vagy a szolgaltatas amit felajanlasz, olyan jellegu, hogy csak fix idoszakokra lehet kerni (pl. domainek)

A kovetkezo tanacsom, hogy az ido kiszamitasanal a teljes rendszered mukodjon UTC-ben, kulonben nagyon brutalis remalmok fognak kiserteni a teli-nyari idoszamitas teren, foleg ha kerekitesz is.

Aztan, ami a szamlakat illeti, ugy kell megoldani, hogy lockokat alkalmazol az adatbazison es ket lepesben csinalod meg, amit meg kell. Az elso korben osszegyujtod az adatokat, a masodikban allitod ki a szamlat. Igy, ha megszakad, ujra tudod kezdeni.

A csomagvaltasokra egyedi megoldasok vannak, annak fuggvenyeben, hogy milyen fizetesi modjaid vannak. Itt figyelembe kell venni azt is, hogy vannak kesleltetett fizetesi modok, pl atutalas, ergo azokat megfeleloen kell kezelni.

Amit szinten akarsz, az egy olyan rendszer, ami minden felhasznalonak fenntart egy "egyenleget" vagy "bankszamlat" a rendszerben, hiszen lehetnek stornoid, stb. es ha ezt nem csinalod meg, remalom lesz kezelni az ilyeneket, a tulfizeteseket, stb.