Luna trecuta un client ne-a intrebat: "De ce mi-au disparut 3 abonati? N-au anulat nimic."
Raspunsul: cardurile lor au expirat. Stripe a incercat sa le taxeze, a esuat, a mai incercat de 3 ori, si dupa 3 saptamani i-a marcat ca "unpaid". Clientul nu stia ca se intampla asta pentru ca nu avea dunning configurat.
Asta e un scenariu pe care il vedem des. Platile recurente par simple — un buton de "Aboneaza-te" si gata. Dar in spatele acelui buton sunt zeci de edge cases care, neglijate, iti pierd bani in fiecare luna. Articolul asta iti arata exact ce se intampla si cum sa previi pierderile.
Raspuns scurt
Platile recurente functioneaza prin Stripe Subscriptions: la fiecare ciclu de facturare, Stripe genereaza automat o factura si incearca sa taxeze cardul. Cand plata esueaza (8-12% din cazuri), intra procesul de dunning — retry-uri automate + email-uri catre client. Fara dunning configurat, pierzi 5-7% din venituri anual. Cu dunning, recuperezi 62% din platile esuate. Cele mai importante de implementat din prima zi: webhook handlers, email-uri de dunning si notificare de card expiring.
Pentru cine este acest articol
- Fondatori de SaaS care vor sa inteleaga cum functioneaza billing-ul inainte sa-l implementeze
- Antreprenori cu produse pe abonament (cursuri, membership, tooluri) care pierd abonati fara sa stie de ce
- Developeri care implementeaza Stripe Subscriptions pentru prima data
- Oricine vrea sa inteleaga de ce platile recurente nu sunt "set and forget"
Anatomia unei plati recurente
Cand un user introduce cardul si alege un plan de 49 RON/luna, se intampla urmatoarele:
1. Stripe creeaza un Customer (obiect care tine datele de facturare)
2. Creeaza un Subscription legat de un Price (49 RON, recurent, lunar)
3. Genereaza prima Invoice si incearca plata
4. Daca plata reuseste, trimite un webhook catre serverul nostru
5. Serverul nostru primeste evenimentul `invoice.paid` si activeaza contul
Asta e flow-ul fericit. Dar flow-ul fericit e doar 85-90% din realitate.
Cand lucrurile nu merg — cifrele reale
Conform datelor noastre din ultimele 12 luni pe proiectele gestionate:
| Metric | Valoare |
|--------|---------|
| Plati esuate la prima incercare | 8-12% |
| Recuperate cu retry automat | ~65% din esuate |
| Carduri expirate in orice luna | 3-4% din abonati |
| Venituri pierdute fara dunning | 5-7% anual |
| Venituri pierdute cu dunning | ~1% anual |
La 500 de useri si 49 RON/luna, 5% inseamna ~14.700 RON pierduti pe an. Bani care se puteau recupera automat.
Cifrele astea nu sunt dramatice pentru un SaaS cu 50 de useri — dar daca te intrebi cat costa o platforma SaaS, billing-ul corect e o parte esentiala din buget.
Ce e un webhook si de ce conteaza
Un webhook e un mesaj pe care Stripe il trimite la serverul tau cand se intampla ceva. Plata a reusit. Plata a esuat. Clientul si-a anulat abonamentul. Cardul expira luna viitoare.
Fara webhooks, aplicatia ta nu stie ce se intampla cu platile. E ca si cum ai avea un magazin fara casa de marcat — clientul plateste, dar tu nu afli.
Noi ascultam cam 12 tipuri de webhooks pe fiecare proiect SaaS:
- `invoice.paid` — activeaza/reinnoieste accesul
- `invoice.payment_failed` — trimite email utilizatorului
- `customer.subscription.deleted` — dezactiveaza contul
- `customer.subscription.updated` — schimbari de plan
- `customer.source.expiring` — avertizare card care expira
Fiecare webhook trece printr-un handler care verifica semnatura (ca sa nu acceptam mesaje false), proceseaza evenimentul si logheaza tot. Daca handler-ul crapa, Stripe reincearca de pana la 10 ori in 3 zile.
---
Ai un SaaS si vrei billing care nu pierde bani? Configuram Stripe complet — webhooks, dunning, billing portal, facturare — intr-o saptamana.
---
Dunning: banii pe care ii recuperezi dormind
Dunning e procesul de recuperare a platilor esuate. Suna sofisticat, dar in practica e simplu:
Retry automat: Stripe reincearca plata esuata dupa 1 zi, apoi dupa 3 zile, apoi dupa 5 zile. Configurabil. Noi setam 3 retry-uri pe parcursul a 14 zile.
Email-uri automate: La fiecare retry esuat, trimitem un email. Nu generic — personalizat, cu link direct catre pagina de update card.
| Momentul | Mesajul | Rezultat |
|----------|---------|----------|
| Imediat dupa esec | "Plata ta de 49 RON nu a putut fi procesata. Actualizeaza cardul aici." | Recupereaza ~30% |
| Dupa 3 zile | "Inca nu am reusit sa procesam plata. Accesul va fi suspendat in 7 zile." | Recupereaza ~20% |
| Dupa 7 zile | "Ultima incercare. Dupa 48 de ore contul va fi dezactivat." | Recupereaza ~12% |
Rata totala de recuperare cu cele 3 email-uri: 62% din platile initial esuate. Fara email-uri, doar retry-ul automat recupereaza cam 40%.
Perioade de trial
Free trial de 7 sau 14 zile. Simplu, nu? Nu chiar.
Intrebari pe care trebuie sa le rezolvi:
- Ceri cardul la inceput sau la sfarsit? Noi cerem la inceput — rata de conversie e mai mare cu 35% fata de "card la sfarsit", dar mai putini se inscriu initial
- Ce se intampla daca user-ul nu face nimic dupa trial? Taxare automata sau suspendare?
- Trimiti reminder inainte de sfarsitul trial-ului? Da, cu 2 zile inainte — obligatoriu legal in UE
Stripe gestioneaza trial-ul nativ. Setezi `trial_period_days: 14` pe subscription si nu factureaza nimic pana la sfarsit. Primesti un webhook `customer.subscription.trial_will_end` cu 3 zile inainte.
Schimbari de plan si prorare
Clientul tau are planul Basic la 29 RON/luna. Vrea sa treaca pe Pro la 79 RON/luna. Ce se intampla cu banii?
Proration (ce folosim noi): Stripe calculeaza cat a folosit din luna curenta pe planul vechi si cat datoreaza pe planul nou. Daca e la jumatatea lunii, plateste diferenta de ~25 RON imediat si de luna viitoare plateste 79 RON.
Fara proration: Planul nou intra in vigoare de la urmatoarea factura. User-ul are acces la Pro imediat dar plateste abia luna viitoare. Mai simplu, dar pierzi bani daca upgrade-ul e la inceputul ciclului.
Cat cod inseamna un modul de billing
Nu o sa intru in detalii de implementare (dar poti vedea un exemplu concret in platforma de cursuri pe care am construit-o). Ca sa intelegeti volumul: un modul complet de billing are cam 800-1.200 de linii de cod server-side. Include:
- Creare si gestionare subscriptions
- 12 webhook handlers
- Logica de dunning (email-uri + retry config)
- Portal de billing pentru user (Stripe Customer Portal)
- Gestionare taxe (TVA pentru UE)
- Logging pentru debugging
Nu e rocket science, dar sunt multe edge cases. Ce se intampla daca webhook-ul vine de 2 ori? Daca user-ul face upgrade si downgrade in aceeasi zi? Daca banca refuza fara motiv si apoi aproba la retry?
Checklist rapid — billing care nu pierde bani
- [ ] Stripe configurat cu webhooks (minim 5 tipuri esentiale)
- [ ] Dunning activ din prima zi — nu "cand o sa am mai multi useri"
- [ ] Email-uri de dunning personalizate cu link de update card
- [ ] Email de card expiring cu 30 de zile inainte
- [ ] Retry automat: 3 incercari pe 14 zile
- [ ] Logging complet pe toate webhook-urile
- [ ] Stripe Customer Portal activ pentru self-service
- [ ] Reminder inainte de sfarsitul trial-ului (obligatoriu UE)
Cand merita investitia in billing profesional
Merita din prima zi:
- SaaS cu plati recurente (orice numar de useri)
- Platforme de cursuri sau membership cu abonament
- Orice produs unde churn involuntar = bani pierduti
Poate astepta:
- MVP in faza de validare cu sub 10 useri platitori
- Produse cu plata unica (nu recurenta)
- Proiecte unde monetizarea nu e inca clara
Obiectii frecvente
"Am doar 50 de useri, dunning-ul nu merita efortul acum."
La 50 useri x 49 RON, 5% pierdut inseamna ~1.470 RON/an. Nu e dramatic. Dar dunning-ul se configureaza o data si functioneaza automat. Costul de setup e zero daca il faci de la inceput si scump daca il adaugi retroactiv.
"Stripe se ocupa de tot automat, nu trebuie sa fac nimic."
Stripe face retry automat, dar nu trimite email-uri personalizate, nu notifica user-ul ca are cardul expirat si nu-ti spune ca pierzi abonati. Fara webhook handlers proprii, esti orb.
"Nu vreau sa deranjez clientii cu email-uri de plata."
Clientii nu s-au dezabonat. Cardul le-a expirat sau banca a refuzat temporar. Majoritatea vor sa plateasca — doar trebuie sa afle ca e o problema. Un email politicos cu link de update card nu deranjeaza, recupereaza.
Intrebari frecvente
Cum functioneaza platile recurente cu Stripe?
Stripe creeaza un obiect Subscription legat de un Customer si un Price. In fiecare luna (sau la intervalul setat), genereaza automat o factura si incearca sa taxeze cardul. Daca reuseste, trimite un webhook catre serverul tau. Daca esueaza, intra in procesul de retry. Am detaliat ghidul complet Stripe in Romania cu toate comisioanele si configurarile.
Ce e dunning si de ce e important?
Dunning e procesul automat de recuperare a platilor esuate. Include retry-uri automate (Stripe reincearca plata la intervale configurabile) si email-uri catre client cu link de actualizare card. Fara dunning, pierzi 5-7% din venituri anual din plati care se puteau recupera.
Cat la suta din plati esueaza in medie?
Intre 8 si 12% la prima incercare, conform datelor noastre. Cauzele principale: card expirat, fonduri insuficiente sau banca care refuza temporar. Cu retry automat si dunning, 62-65% din aceste plati se recupereaza.
Ce comisioane are Stripe pentru plati recurente in Romania?
1.5% + 0.25 EUR per tranzactie pentru carduri europene. Pentru carduri non-europene, 2.5% + 0.25 EUR. Nu exista comisioane suplimentare pentru plati recurente fata de plati one-time. Stripe retine comisionul automat si vireza restul.
Pot oferi perioada de trial gratuit cu Stripe?
Da. Setezi `trial_period_days` pe subscription si Stripe nu factureaza nimic pana la sfarsitul trial-ului. Primesti un webhook cu 3 zile inainte de sfarsitul trial-ului ca sa trimiti reminder. Poti cere cardul la inceput sau la sfarsit — noi recomandam la inceput pentru conversie mai buna.
Cat costa integrarea unui sistem de plati recurente?
Un modul complet de billing (subscriptions, webhooks, dunning, portal, TVA) necesita 800-1.200 linii de cod si 1-2 saptamani de dezvoltare. Costul variaza intre 1.500 si 3.000 EUR, in functie de complexitatea planurilor si a logicii de business.
Ce se intampla cand un client isi anuleaza abonamentul?
Stripe trimite un webhook `customer.subscription.deleted`. Serverul dezactiveaza accesul la sfarsitul perioadei platite (nu imediat). Clientul poate folosi serviciul pana la data la care a platit. Daca vrei, poti implementa si un flow de retentie cu oferta de discount inainte de anulare.
Urmatorul pas
Platile recurente nu sunt complicate conceptual. Sunt complicate operational. Si diferenta dintre un SaaS care pierde 7% din venituri si unul care pierde 1% e exact in aceste detalii.
Ai un SaaS sau un produs cu abonament si vrei billing care nu pierde bani? Configuram Stripe complet — webhooks, dunning, billing portal, facturare — intr-o saptamana.
Programeaza o discutie gratuita
Fara obligatii. Daca Stripe nu e potrivit pentru cazul tau, iti recomandam alternativa.