Recurring payments: arhitektura pretplata i automatske naplate

Recurring payments su model u kome se kupcu, uz prethodno definisanu saglasnost, naplata ponavlja prema određenom rasporedu: mesečno, godišnje ili po drugom obračunskom periodu. Za korisnika to može izgledati kao jedno polje za karticu i potvrda pretplate. Iza tog koraka, međutim, postoji sistem koji mora da zna šta je kupljeno, kada se naplata pokreće, kako se čuva referenca na payment method, šta se dešava kada banka odbije transakciju i kada korisnik otkaže uslugu.

Zato se integracija recurring payments ne projektuje kao dodatak checkout formi, već kao kombinacija poslovnih pravila, payment gateway-a, korisničkog naloga i pouzdane obrade događaja. Najvažnija odluka je da se odvoje status pretplate, status fakture ili obračuna i status konkretne naplate. Kada se ta tri pojma pomešaju, nastaju duple aktivacije, prerano ukidanje pristupa ili evidencija da je korisnik platio iako je naplata još u obradi.

U nastavku je arhitektonski okvir za recurring payments integraciju: od modela pretplate i tokenizacije do webhooks-a, retry logike, autentikacije, refundiranja i testiranja. Ako je potrebno povezati kartično plaćanje sa konkretnim web-sajtom ili aplikacijom, ovaj okvir treba posmatrati zajedno sa širim zahtevima za integraciju platnih kartica, koja obuhvata izbor procesora, checkout i povezivanje sa poslovnim sistemima.

Od čega se sastoji sistem za automatsku naplatu

Pre izbora tehničkog rešenja treba nacrtati tok novca i tok statusa. U tipičnoj pretplati učestvuju sledeće komponente:

• Frontend ili checkout prikazuje plan, cenu, period, uslove i prikuplja saglasnost kupca.
• Payment gateway ili procesor obrađuje inicijalnu transakciju i, u skladu sa podržanim modelom, kasnije naplate.
• Payment method reference ili token predstavlja bezbednu referencu na karticu, umesto čuvanja sirovih podataka kartice u aplikaciji.
• Subscription servis čuva plan, ciklus, datum sledeće naplate, status i pravila promene paketa.
• Billing ili invoicing sloj određuje šta se naplaćuje za dati period, uključujući proporcionalne iznose kod promene plana.
• Webhook endpoint prima serverske događaje procesora i menja stanje u sopstvenoj bazi.
• Administracija i korisnički portal omogućavaju pregled pretplate, promenu payment metode, otkazivanje, fakture i komunikaciju sa korisnikom.

Ove komponente mogu biti u jednom payment proizvodu ili raspoređene između više servisa. Ključno nije da arhitektura bude velika, već da svaka komponenta ima jasno vlasništvo nad podacima. Na primer, payment gateway zna ishod pokušaja naplate, dok vaša aplikacija zna da li aktivan plan daje pristup određenoj funkciji.

Model podataka: plan, pretplata, obračun i naplata

Najčešća greška je čuvanje samo polja poput subscription_active = true. Takav model ne može pouzdano da objasni prelazak sa mesečnog na godišnji plan, neuspeh jedne rate, probni period ili zakašnjeli webhook. Minimalni domen obično treba da razlikuje sledeće entitete:

U bazi je korisno čuvati i identifikatore koje vraća payment sistem, ali uz jasnu razliku između internog ID-ja i spoljnog ID-ja. Spoljni identifikator treba koristiti za korelaciju događaja, podršku i pomirenje podataka, ne kao jedini izvor poslovnog stanja. Iznose treba zapisivati bez oslanjanja na decimalnu aritmetiku u floating-point formatu, uz eksplicitnu valutu i pravila za zaokruživanje.

Definišite životni ciklus pre pisanja integracije

Pretplata može proći kroz više stanja: kreirana, u probnom periodu, aktivna, u obradi, u kašnjenju, otkazana sa pristupom do kraja perioda, završena ili suspendovana. Nazivi nisu univerzalni i zavise od sistema, ali poslovno značenje mora biti precizno. Posebno definišite:

• da li otkazivanje prekida pristup odmah ili tek na kraju plaćenog perioda;
• da li neuspešna naplata odmah ukida pristup ili pokreće grace period;
• šta se dešava kada se korisnik vrati sa novom karticom;
• kako se obračunava promena plana usred ciklusa;
• da li se probni period pretvara u plaćenu pretplatu automatski i pod kojim uslovima.

Ovo nisu samo UX odluke. One određuju koje webhook događaje očekujete, kada izdajete pristup i kako podrška objašnjava status korisniku.

Tokenizacija i čuvanje payment metode

Aplikacija ne bi trebalo da čuva broj kartice, sigurnosni kod i druge osetljive podatke ako za to nema nužan razlog, odgovarajuću PCI DSS kontrolu i procesorsku podršku. U uobičajenom modelu podatke kartice prikuplja hostovani ili procesorski kontrolisan element, a aplikacija dobija token ili referencu koju kasnije koristi za naplatu. Ta referenca nije „kartica u bazi”; ona je veza sa payment sistemom i može imati ograničenja, rok ili zahtev za ponovnu autentikaciju.

Pri dizajniranju treba proveriti šta tačno procesor podržava za card-on-file i iniciranje kasnijih merchant-initiated transakcija. Nije dovoljno pretpostaviti da će svaka kartica i svaka banka prihvatiti automatsko terećenje bez interakcije korisnika. Pravila zavise od procesora, zemlje, šeme kartice, vrste saglasnosti i načina na koji je inicijalno plaćanje potvrđeno.

Korisniku treba omogućiti da vidi razumljiv opis sačuvane metode, na primer brend i poslednje četiri cifre, ali ne i kompletan broj kartice. Promena kartice mora biti zaseban i bezbedan tok. Ako nova metoda ne može da se potvrdi ili sačuva, postojeća pretplata ne sme tiho nestati iz sistema; treba prikazati jasan status i sledeći korak.

Consent, transparentnost i 3-D Secure

Za recurring payments saglasnost nije skrivena tehnička sitnica. Checkout treba jasno da prikaže naziv plana, cenu, učestalost naplate, valutu, datum prve i narednih naplata, pravila otkazivanja i način na koji korisnik može da promeni ili ukloni payment metodu. Evidencija saglasnosti treba da bude povezana sa konkretnim planom i verzijom uslova koji su važili u trenutku aktivacije.

Inicijalno plaćanje može zahtevati dodatnu autentikaciju kupca, uključujući 3-D Secure tok. To ne znači da će svaka naredna naplata izgledati isto. Kada se uvodi autentikacija ili kada je potreban povratak korisnika u checkout, taj tok mora biti predviđen u interfejsu: korisnik dobija objašnjenje, završava potvrdu i vraća se na pouzdano osvežen status. Za detalje o tome kako dodatna autentikacija menja tok plaćanja, koristan je tekst 3-D Secure 2 i checkout.

Ne treba tretirati preusmeravanje ili rezultat sa klijentske strane kao konačnu potvrdu uplate. Konačno poslovno stanje treba zasnivati na serverskoj potvrdi payment sistema i pravilnoj obradi događaja.

Webhooks: izvor događaja, ne običan callback

Kod pretplata se naplata često izvršava asinhrono. Zahtev za naplatu može biti prihvaćen, obrađen kasnije, odbijen, ponovljen ili promenjen nakon dodatne autentikacije. Zato webhook endpoint mora biti projektovan kao pouzdan prijemnik događaja, a ne kao pomoćna funkcija.

Četiri pravila pouzdane obrade

1. Proverite autentičnost događaja. Validirajte potpis ili drugi mehanizam koji propisuje payment platforma i odbijte neproverene zahteve.
2. Učinite obradu idempotentnom. Isti događaj može stići više puta. Sačuvajte event ID i obezbedite da ponovljena obrada ne aktivira pristup ili ne izda refund drugi put.
3. Ne pretpostavljajte redosled. Događaji mogu kasniti ili stići van očekivanog redosleda. Poslovna logika mora da proveri trenutno stanje i vremenski kontekst.
4. Odgovorite brzo, obradite pouzdano. Prijem događaja može biti odvojen od težeg posla kroz red poruka ili pozadinski proces, uz logovanje grešaka i kontrolisani retry.

Primer: nakon uspešnog plaćanja, webhook ne bi trebalo samo da postavi korisnika na „active“. Treba pronaći odgovarajuću pretplatu, proveriti da li događaj pripada očekivanom obračunu, evidentirati payment attempt i tek tada otvoriti ili produžiti pristup. Ako se webhook obradi dvaput, rezultat mora ostati isti.

Za širi prikaz putanje kartične transakcije od checkouta do potvrde, pogledajte kako teče online kartična transakcija. Kod recurring payments taj tok se ponavlja, ali bez punog korisničkog checkouta u svakom ciklusu, zbog čega su statusi i serverski događaji još važniji.

Failed payments i dunning logika

Neuspešna naplata nije isto što i otkazana pretplata. Kartica može biti privremeno odbijena, isteći, imati limit ili zahtevati novu autentikaciju. Sistem zato treba da razlikuje razlog neuspeha kada ga procesor dostavlja i da na osnovu njega odredi sledeći korak.

Dunning je proces pokušaja oporavka naplate i komunikacije sa korisnikom. Dobar tok može obuhvatiti:

• ponovni pokušaj prema pravilima procesora i poslovnoj toleranciji;
• poruku koja korisniku objašnjava da je potrebna akcija, bez otkrivanja nepotrebnih tehničkih detalja;
• bezbedan link ili portal za ažuriranje payment metode;
• grace period u kome pristup nije odmah prekinut;
• jasan prelaz u suspendovano ili otkazano stanje ako oporavak ne uspe.

Broj i raspored pokušaja ne treba naslepo kopirati iz drugog sistema. Zavise od prirode usluge, ugovora, očekivanja korisnika i pravila procesora. Takođe, retry ne sme da izazove duplu naplatu ako je prvi pokušaj zapravo uspeo, ali je odgovor kasnio. Za operativni deo ovog problema pogledajte vodič failed payments i dunning.

Promena plana, otkazivanje i refund

Promena plana zahteva odluku da li se novi paket primenjuje odmah, na sledećem ciklusu ili kroz proporcionalni obračun. Svaka opcija ima trade-off: trenutna promena je fleksibilnija, ali uvodi složeniji obračun; promena na kraju perioda je predvidljivija, ali može biti manje pogodna za korisnika. Pravilo mora biti isto u interfejsu, bazi, fakturi i komunikaciji.

Otkazivanje takođe treba da ima eksplicitno značenje. „Otkazano“ može značiti da nema budućih obnova, ali da je već plaćen pristup aktivan do kraja perioda. U tom slučaju čuvajte datum prestanka i sprečite sledeći renewal, umesto da odmah uklonite sve privilegije.

Refund i partial refund treba modelovati kao zasebne finansijske događaje, ne kao izmenu originalne naplate. Evidentirajte ko je pokrenuo refund, za koji iznos, prema kojoj naplati i da li je refund prihvaćen, u obradi ili završen. Dodatni primeri poslovnih pravila nalaze se u tekstu refund i partial refund.

Arhitektonske opcije i njihovi kompromisi

Hosted checkout ili payment komponenta

Hosted checkout smanjuje količinu payment UI-ja i bezbednosne logike koju tim sam održava. Kompromis je manja kontrola nad iskustvom i ponekad složeniji prelaz između vašeg sajta i payment stranice. Payment komponenta ugrađena u checkout daje više kontrole nad dizajnom i validacijom, ali zahteva pažljivije testiranje, upravljanje greškama i praćenje promena SDK-a.

Payment platforma kao subscription engine

Kada payment platforma vodi planove, cikluse i retry pravila, implementacija može biti jednostavnija. Ipak, potrebno je mapirati njene statuse na sopstveni domen i proveriti da li podržava lokalnu valutu, dostupne metode, fakturisanje, poreska pravila i željeni nivo kontrole. Ne treba pretpostaviti da naziv statusa u dashboardu ima isto značenje kao status u vašoj aplikaciji.

Sopstveni billing sloj

Vlastiti billing sloj je opravdan kada postoje složeni paketi, usage-based obračun, više izvora prihoda ili specifična pravila. Tada payment sistem obavlja naplatu, dok vaša aplikacija računa obavezu. Cena je veća složenost: morate rešiti zaokruživanje, proraciju, fakture, retry, pomirenje i audit trag. Za jednostavnu periodičnu pretplatu takva arhitektura može biti nepotrebno opterećenje.

Šta testirati pre produkcije

Test plan ne treba da pokrije samo uspešno unošenje kartice. Potrebno je proći ceo životni ciklus i proveriti stanje u aplikaciji, payment dashboardu, e-mailovima i administraciji.

• uspešnu inicijalnu kupovinu i aktivaciju pristupa;
• zahtev za dodatnu autentikaciju i povratak na sajt;
• ponovljeni webhook i događaj koji kasni;
• odbijenu prvu naplatu, uspešan retry i trajni neuspeh;
• isteklu ili zamenjenu karticu;
• promenu plana na početku i usred obračunskog perioda;
• otkazivanje odmah i otkazivanje sa pristupom do kraja perioda;
• pun i delimičan refund;
• valutu, vremensku zonu, datum kraja meseca i zaokruživanje;
• gubitak odgovora, dupli klik i prekid mreže tokom checkouta.

Pre puštanja definišite i operativne provere: kako se porede interne evidencije sa payment sistemom, ko dobija obaveštenje kada webhook obrada stane i kako podrška može da pronađe konkretnu pretplatu preko internog i spoljnog identifikatora. Bez pomirenja podataka, greška može ostati neprimećena sve dok se korisnik ne javi.

Kako povezati recurring payments sa web-sajtom

Ako sajt tek nastaje ili se postojeći frontend menja, payment arhitekturu treba uskladiti sa navigacijom, nalozima, CMS-om i administracijom. To je razlog da se recurring payments ne dodaju tek nakon dizajna checkouta. Tok pretplate utiče na stranice plana, prijavu korisnika, portal za billing, e-mail obaveštenja i prikaz statusa u nalogu.

Kod novog projekta, zahtev za subscription logiku treba uključiti u specifikaciju i izradu sajta, a ne tretirati ga kao izolovanu formu za karticu. Kod postojećeg sistema prvo treba popisati gde se trenutno čuvaju korisnik, narudžbina, pristup i finansijski dokumenti. Tek tada se može odlučiti da li je dovoljna integracija payment platforme ili je potreban poseban billing sloj.

Praktična kontrolna lista za odluku

1. Definišite šta se naplaćuje, u kojoj valuti i kojim intervalom.
2. Nacrtajte životni ciklus pretplate i pravila za pristup.
3. Proverite podršku procesora za sačuvane payment metode i kasnije naplate.
4. Odredite koji sistem je izvor istine za naplatu, a koji za pristup usluzi.
5. Projektujte webhook obradu sa verifikacijom, idempotencijom i logovanjem.
6. Definišite neuspele naplate, retry, grace period i komunikaciju.
7. Uskladite 3-D Secure i saglasnost sa konkretnim checkout tokom.
8. Dokumentujte promenu plana, otkazivanje, refund i partial refund.
9. Testirajte rubne slučajeve pre stvarne naplate.
10. Obezbedite administrativni pregled i proces pomirenja podataka.

Najbolji sledeći korak nije odmah izbor plugina ili kopiranje tuđeg checkouta, već kratak opis poslovnih pravila: planovi, ciklus, statusi, pristup, otkazivanje i način oporavka neuspele naplate. Na osnovu tog opisa može se proceniti da li je dovoljna standardna subscription funkcionalnost payment platforme ili je potrebna prilagođena integracija platnih kartica.