Subscription web shop je prodajni sistem u kome kupac ne obavlja samo jednu transakciju, već ulazi u odnos koji se periodično obnavlja. Zato se uspešna implementacija ne završava na stranici proizvoda i dugmetu „Kupi“. Potrebno je jasno definisati šta kupac dobija, kada se naplata ponavlja, kako se menja plan i šta se dešava ako obnova ne uspe.
Najvažnija odluka je da se pretplata posmatra kao lifecycle, a ne kao posebna vrsta proizvoda. Taj lifecycle obuhvata izbor plana, početnu naplatu, aktivaciju pristupa, buduće obnove, obaveštenja, neuspele pokušaje naplate, pauzu, promenu paketa i konačno otkazivanje. Ako se ti koraci unapred ne modeluju, problemi se najčešće pojavljuju tek posle prve serije obnova.
Šta subscription web shop treba da rešava
Pre izrade treba zapisati poslovna pravila koja će platforma, payment gateway i korisnički nalog sprovoditi. Minimum obično uključuje:
- koji proizvodi ili usluge mogu da se kupuju kroz pretplatu;
- da li se pretplata naplaćuje mesečno, godišnje ili po drugom ciklusu;
- da li postoji probni period, početna naknada ili jednokratna aktivacija;
- da li kupac može da promeni paket usred ciklusa;
- da li se kod promene plana radi trenutni obračun razlike ili promena važi od naredne obnove;
- koliko dugo sistem pokušava da naplati neuspelu obnovu;
- šta kupac gubi nakon otkazivanja i da li pristup traje do kraja već plaćenog perioda.
Ova pravila pripadaju specifikaciji izrade web shopa, ali subscription model zahteva dodatnu pažnju prema stanju pretplate i komunikaciji posle kupovine. Head komercijalni deo projekta može biti na stranici usluge, dok se ovde fokus zadržava na periodičnoj naplati i operativnoj logici.
Koji model pretplate odgovara ponudi
Nisu sve pretplate iste. Model treba povezati sa načinom isporuke, maržom, učestalošću korišćenja i očekivanjem kupca.
Periodična isporuka proizvoda
Kupac dobija fizički proizvod u ponavljajućem intervalu: na primer potrošni materijal, odabrani asortiman ili paket proizvoda. Web shop tada mora da poveže pretplatu sa zalihama, adresom, troškom dostave i promenama porudžbine. Ako se cena dostave razlikuje po zoni ili težini, to pravilo treba rešiti pre aktivacije pretplate, a ne ručnim obračunom nakon obnove.
Korisno je unapred definisati da li kupac može da preskoči jednu isporuku, promeni adresu ili doda jednokratni proizvod. Dodatna kupovina ne bi trebalo automatski da promeni periodičnu naknadu bez jasnog prikaza.
Digitalni pristup ili članstvo
Kod digitalnog proizvoda pretplata najčešće kontroliše pristup sadržaju, funkcijama ili korisničkom nalogu. Ključna integracija nije samo naplata, već veza između statusa pretplate i dozvola u aplikaciji. Nakon uspešne uplate korisnik treba da dobije odgovarajući pristup, a nakon isteka ili otkazivanja sistem treba predvidivo da promeni status.
Ovakav model se može povezati sa funkcionalnostima korisničkog naloga i pogodnostima za lojalne kupce. Ako su bodovi, statusi ili pogodnosti deo ponude, pravila treba uskladiti sa lifecycle-om pretplate. Više o toj temi obrađeno je u vodiču loyalty program u web shopu.
Više planova, paketa ili nivoa
Subscription web shop može nuditi osnovni, napredni i poslovni plan, ali veći broj opcija povećava zahtevnost checkouta, korisničkog naloga i podrške. Za svaki plan treba navesti šta je uključeno, period naplate, ograničenja, način otkazivanja i pravila prelaska na drugi nivo.
Dobro je razlikovati naziv paketa od tehničkog identifikatora plana. Naziv može da se promeni zbog komunikacije, dok stabilan identifikator pomaže da se istorija korisničke pretplate i izveštaji ne poremete.
Lifecycle plaćanja: od checkouta do obnove
Lifecycle treba nacrtati kao niz stanja, a ne kao jednu porudžbinu. Tipičan tok može izgledati ovako:
- Izbor plana: kupac bira učestalost i eventualne dodatke.
- Checkout: prikazuju se iznos, porezi ili naknade gde je primenljivo, datum prve i naredne naplate i uslovi otkazivanja.
- Autorizacija plaćanja: payment provider obrađuje početnu transakciju ili postavlja metod plaćanja za buduće naplate, u skladu sa svojim pravilima.
- Aktivacija: tek nakon pouzdane potvrde uspešne naplate ili drugog definisanog događaja aktiviraju se pristup, porudžbina i obaveštenje.
- Obnova: sistem pokreće periodičnu naplatu i upisuje rezultat u istoriju korisnika.
- Izuzetak: ako naplata ne uspe, pokreće se definisani proces ponovnog pokušaja i obaveštavanja.
- Završetak: pretplata se otkazuje, pauzira, ističe ili prelazi u drugo stanje prema pravilima poslovanja.
Važno je da web shop ne zaključuje da je uplata uspešna samo zato što je korisnik vraćen na stranicu „Hvala“. Za potvrdu stanja koriste se događaji i statusi payment sistema, a implementacija mora da spreči duplu obradu istog događaja. Konkretni mehanizmi zavise od izabranog provajdera i platforme.
Obnova pretplate i neuspele naplate
Obnova je trenutak kada se vidi da li je model zaista operativan. Kartica može isteći, banka može odbiti transakciju, korisnik može imati nedovoljno sredstava ili zahtev može zahtevati dodatnu autentifikaciju. Zbog toga „neuspešno plaćanje“ ne treba tretirati kao jednu univerzalnu situaciju.
Za svaki tip greške treba definisati sledeće:
- da li se naplata automatski ponavlja i u kom intervalu;
- koliko pokušaja postoji pre promene statusa pretplate;
- da li korisnik zadržava pristup ili se pristup privremeno ograničava;
- koje poruke dobija kupac i preko kog kanala;
- da li administrator vidi razlog i sledeću zakazanu akciju;
- kako se evidentira konačni otkaz ili povrat sredstava.
Automatsko ponovno pokušavanje može smanjiti potrebu za ručnom intervencijom, ali ne rešava svaki uzrok odbijanja. Zato kupcu treba ponuditi bezbedan način da ažurira metod plaćanja, bez slanja podataka o kartici kroz email ili nebezbedne forme. Dokumentacija payment provajdera treba da bude merodavna za konkretne statuse, retry logiku i webhooks.
Promena plana, pauza i otkazivanje
Korisnički nalog treba da omogući kontrolisane promene, umesto da podrška ručno menja podatke u bazi. Najčešće opcije su:
| Akcija | Šta treba unapred definisati |
|---|---|
| Upgrade | Da li novi plan važi odmah i kako se obračunava razlika. |
| Downgrade | Da li se promena primenjuje odmah ili od sledeće obnove. |
| Pauza | Koliko može da traje i da li se naredni datum naplate pomera. |
| Otkazivanje | Da li pristup traje do kraja plaćenog perioda i da li se obnova zaustavlja odmah. |
| Ponovna aktivacija | Da li se nastavlja stari plan ili kupac bira novi. |
Otkazivanje ne bi trebalo sakriti iza nejasnog procesa. Kupac mora da vidi da je zahtev primljen, koji je status pretplate i da li postoji buduća naplata. Ako se fizička roba šalje, otkazivanje pretplate nije isto što i povrat već isporučene porudžbine; ta pravila treba razdvojiti u korisničkom interfejsu i uslovima kupovine.
Korisnički nalog i komunikacija
Za pretplatnički model korisnički nalog je operativni centar, ne samo mesto za pregled ranijih porudžbina. Kupac treba da pronađe:
- aktivni plan i njegove pogodnosti;
- cenu i datum naredne naplate;
- istoriju naplata i porudžbina;
- metod plaćanja, uz bezbedno preusmeravanje na payment sistem kada je potrebno;
- adresu i podatke za isporuku, ako se šalje roba;
- opcije promene, pauze i otkazivanja;
- status poslednje neuspele ili uspešne obnove.
Obaveštenja treba da prate važne događaje: potvrdu početka, najavu obnove ako je poslovno potrebna, uspešnu naplatu, neuspešan pokušaj, promenu plana i otkazivanje. Poruka treba da bude konkretna: koji plan je u pitanju, koji iznos, koja akcija se očekuje i gde korisnik može da reši problem.
Integracije koje često odlučuju o kvalitetu rešenja
Subscription web shop se retko završava u checkoutu. Kod fizičkih proizvoda potrebno je uskladiti obnovu sa stanjem zaliha, skladištem i kurirskom službom. Status plaćanja i status isporuke nisu ista stvar, pa ih treba odvojeno prikazivati korisniku. Za detalje o povezivanju porudžbine, statusa i trackinga pogledajte tekst Dostava i kurirske integracije.
Ako se pretplate prodaju firmama, mogu biti potrebni različiti cenovnici, odobrenja, podaci za fakturisanje i posebna pravila obnove. To nije samo varijacija B2C checkouta, već deo šire B2B strukture web shopa, opisane u vodiču B2B web shop: cenovnici, firme, odobrenja i veleprodaja.
U poslovanju sa fizičkim prodajnim mestima treba razmotriti i vezu sa POS sistemom. Na primer, stanje zaliha, identitet kupca ili pogodnosti mogu se pojavljivati u više kanala, ali to zahteva jasno definisan izvor podataka. Više o toj odluci nalazi se u tekstu POS integracija za fizičku i online prodaju.
Kako birati platformu i payment rešenje
Ne postoji univerzalno najbolja kombinacija. Pri izboru proverite da li rešenje podržava baš model koji prodajete, a ne samo jednokratne kartične transakcije. Relevantna pitanja su:
- Da li postoji podrška za periodične naplate ili je potrebna posebna ekstenzija?
- Kako se čuvaju tokenizovani podaci o payment metodu i ko je odgovoran za osetljive podatke?
- Da li postoje webhooks za uspeh, neuspeh, refundaciju, promenu i otkazivanje?
- Kako se rešavaju dodatna autentifikacija i povratak korisnika u checkout?
- Da li se mogu definisati lokalna pravila za poreze, račune, valutu i fakturisanje?
- Kako se radi migracija postojeće baze pretplatnika ako se platforma promeni?
- Da li administrator može da vidi audit trag i ručno obradi izuzetak bez menjanja istorije?
Za funkcionalnosti koje zavise od konkretnog payment provajdera treba koristiti aktuelnu zvaničnu dokumentaciju, jer se nazivi objekata, podržane metode i pravila mogu menjati. Pre puštanja u rad obavezno proverite podršku za Srbiju, ugovorne uslove, valute, izdavanje računa i poreske obaveze sa relevantnim stručnjacima i odabranim provajderom.
Testiranje pre puštanja u rad
Test plan treba da obuhvati više od uspešne kupovine. Minimalni scenariji su:
- nova pretplata sa uspešnom prvom naplatom;
- obnova sa uspešnom naplatom;
- istekla ili odbijena kartica;
- više neuspešnih pokušaja i prelazak u konačni status;
- promena plana na dan obnove i van tog datuma;
- pauza i ponovna aktivacija;
- otkazivanje pre obnove i posle već izvršene naplate;
- refundacija ili storno, u skladu sa pravilima provajdera;
- duplirani ili zakašnjeli webhook događaj;
- prekid komunikacije između payment sistema, web shopa i sistema za isporuku.
Za svaki scenario treba proveriti korisnički interfejs, email, administraciju, stanje pretplate, porudžbinu, račun i eventualni pristup sadržaju. Posebno testirajte šta se dešava kada korisnik osveži stranicu, klikne više puta ili se vrati u checkout iz drugog taba.
Praktičan sledeći korak
Pre razgovora o dizajnu pripremite tabelu sa planovima, ciklusima naplate, pravilima promene, uslovima otkazivanja, neuspelim scenarijima i integracijama. Zatim za svaki red označite da li ga rešava web shop platforma, payment provajder, dodatna ekstenzija ili prilagođena logika.
Takva specifikacija brzo pokazuje da li je potreban jednostavan model periodične prodaje ili složeniji sistem sa više nivoa, korisničkim portalom, dostavom i poslovnim pravilima. Kada se ova mapa usaglasi, lakše je proceniti obim izrade sajta i precizirati zahtev za izradu web shopa bez mešanja jednokratne prodaje i lifecycle plaćanja.
