Salut — am văzut mesajul tău de dimineață, captura de ecran cu cineva care întreabă „cum te pot plăti pentru asta” în inbox-ul de suport al aplicației tale. Felicitări, sincer. Acesta este momentul în care un proiect personal încetează să mai fie un demo. Este și momentul în care o sută de decizii mărunte pe care le-ai putut amâna apar toate în aceeași marți. M-ai rugat să-ți spun pur și simplu ce să faci. O voi face, dar vreau să te ghidez mai întâi prin motivele din spate, pentru că „de ce”-ul este cel care te scutește să mă întrebi din nou peste trei luni, când în loc de Stripe va fi Lemon Squeezy, sau în loc de plată unică va fi abonament.
Decizia pe care o iei de fapt
Ai formulat-o ca „ce procesator de plăți ar trebui să folosesc”, dar sunt de fapt două decizii suprapuse. Prima: vrei să fii tu comerciantul înregistrat (merchant of record), sau vrei ca altcineva să fie? A doua: care este structura ta de facturare — achiziție unică, abonament sau plată în funcție de utilizare? Dacă greșești la prima, peste șase luni vei petrece un weekend înregistrându-te pentru TVA într-o țară în care nu ai călcat niciodată. Dacă greșești la a doua, este doar o migrare enervantă, nu una legală, deci e mai puțin înfricoșătoare dintre cele două.
A fi comerciantul înregistrat înseamnă că tu ești, din punct de vedere legal, cel care vinde produsul. Tu colectezi banii, tu ești responsabil să calculezi taxa pe vânzări și TVA-ul în fiecare jurisdicție în care locuiesc clienții tăi, și tu depui declarațiile pentru asta. Stripe îți va calcula cu plăcere taxa (Stripe Tax), dar calcularea nu înseamnă și virarea către stat — tot trebuie să te înregistrezi și să depui declarații de fiecare dată când depășești un prag. Un serviciu de tip merchant of record precum Lemon Squeezy sau Paddle preia întreaga problemă de pe biroul tău: ei sunt, legal, vânzătorul, colectează și virează taxele peste tot, iar ție îți plătesc suma netă. În schimb, renunți la o parte din marjă.
| Opțiune | Cine este vânzătorul | Comision tipic | Gestionarea taxelor | Ideal pentru |
|---|---|---|---|---|
| Stripe (direct) | Tu | ~2,9% + 0,30 $/tranzacție, +0,5% pentru Stripe Tax | Tu te înregistrezi și depui declarații, Stripe doar calculează | Te aștepți să crești peste câteva mii pe lună și vrei comisioane mai mici pe termen lung |
| Lemon Squeezy | Lemon Squeezy | ~5% + 0,50 $/tranzacție | Complet gestionat, ei sunt vânzătorul înregistrat | Builder solo, primul produs, nu vrei deloc să te gândești la taxe |
| Paddle | Paddle | ~5% + comisioane variabile în funcție de regiune | Complet gestionat, orientat mai mult spre enterprise | SaaS cu abonamente și unele nevoi de facturare |
| PayPal | Tu | ~3,5-4,5%, dispute favorabile cumpărătorului | Te ocupi tu | Clienți care au încredere specific în PayPal, nu o alegere implicită |
Pentru situația în care te afli acum — un client, un produs simplu, fără să știi încă dacă asta devine o afacere — te-aș îndrepta spre Lemon Squeezy sau Paddle, nu direct spre Stripe. Cele două puncte procentuale în plus la comision sunt o asigurare ieftină împotriva riscului de a deveni, din greșeală, plătitor de taxe într-un stat în care nu ai pus vreodată piciorul. Poți migra ulterior direct la Stripe, odată ce volumul justifică schimbarea și ai stomacul necesar pentru birocrație. Nimeni nu migrează procesatori de plăți de plăcere, dar e o marți rezolvabilă, nu un an rezolvabil.
Am făcut chiar eu această greșeală într-un proiect anterior — m-am dus direct pe Stripe pentru că „toată lumea folosește Stripe”, am colectat câteva sute de dolari pe lună de la câțiva clienți europeni, iar apoi am primit, optsprezece luni mai târziu, un email foarte politicos, dar foarte derutant despre înregistrarea VAT MOSS. M-a costat o după-amiază de contabil și patruzeci de minute de panică pură căutând pe Google „îi datorez bani Olandei”. Nu a fost catastrofal. Dar a fost complet evitabil.
Înainte să atingi cheile live
Indiferent ce alegi, nu conecta totul direct în modul de producție. Fiecare dintre acești furnizori are un mod de test/sandbox cu numere de card false care declanșează rezultate specifice — plată reușită, card refuzat, necesită 3D Secure, fonduri insuficiente. Parcurge-le pe toate înainte să atingi o cheie reală. Căile de eșec sunt cele pe care le vei întâlni efectiv în prima săptămână, și sunt mult mai puțin plăcute de depanat live, cu cardul unei persoane reale implicat.
În chat-ul tău de build, precizează explicit că vrei acest lucru etapizat: cere ca integrarea să fie conectată mai întâi în modul de test, cu un banner sau un flag clar vizibil, astfel încât nimeni — inclusiv tu, în viitor — să nu taxeze din greșeală un card real în timpul testării. Apoi ai un al doilea pas, deliberat, în care înlocuiești cheile cu cele live. Două prompturi, nu unul, chiar dacă ar fi mai rapid să spui doar „adaugă plăți” și să lași sistemul să ghicească modul. Frecarea aceasta este chiar scopul.
Trebuie de asemenea să decizi ce se întâmplă când un webhook se declanșează, iar serverul tău e căzut, lent, sau evenimentul sosește de două ori. Nu e o ipoteză — se întâmplă în prima săptămână, sigur. Evenimentele pe care trebuie neapărat să le gestionezi, la minimum:
checkout.session.completed(sau echivalentul) — acordă accesul, acesta este momentul în care clientul devine efectiv clientinvoice.payment_failed— pentru abonamente, decide acum dacă asta înseamnă blocare instantanee sau o perioadă de grație, pentru că „blocare instantanee” este o primă impresie chiar proastă pentru un card care a avut doar o problemă temporarăcustomer.subscription.deleted— cineva a anulat, revocă accesul la sfârșitul perioadei, nu imediat, cu excepția cazului în care termenii tăi spun altfel- Un eveniment de rambursare — decide o singură dată, în scris pentru tine însuți, care este de fapt politica ta de rambursare, înainte ca prima cerere de rambursare să te forțeze să decizi pe loc
Idempotența contează aici mai mult decât aproape oriunde altundeva în aplicația ta. Dacă un webhook sosește de două ori — și va sosi, furnizorii reîncearcă la orice răspuns diferit de 200 — nu poți acorda accesul de două ori sau, și mai rău, dubla starea internă de taxare. Salvează ID-ul evenimentului și verifică dacă nu l-ai procesat deja înainte de a acționa pe baza lui.
Întrebarea legată de preț pe care o eviți
Ai menționat în mesajul tău că nu erai sigur dacă să taxezi 9 $/lună sau o singură dată 49 $. Nu cred că vreuna dintre variante e greșită, dar observă ce eviți de fapt: discuția cu clientul despre care este valoarea recurentă. Un preț unic este mai ușor de acceptat și mai ușor de construit pentru tine (fără dunning, fără gestionarea reînnoirilor eșuate, fără flux de anulare). Un abonament este un pariu că vei continua să îmbunătățești produsul suficient încât oamenii să nu renunțe — ceea ce este un angajament real, nu doar o bifă pe o pagină de prețuri. Dacă nu ești sigur că vei mai lucra activ la asta peste șase luni, un preț unic este oferta mai onestă. Poți adăuga oricând mai târziu un nivel de abonament, odată ce există ceva continuu la care să te abonezi.
Încă un lucru, apoi te las să te întorci la treabă: pune o politică reală de rambursare și anulare pe pagină înainte să încasezi primul dolar, chiar dacă sunt doar trei propoziții. Nu pentru că cineva te va da în judecată pentru o taxă de 9 $, ci pentru că scrierea ei te obligă să decizi cu adevărat, iar „o să văd atunci când mă întreabă cineva” este exact modul în care ajungi să iei o decizie de politică în mijlocul unui email furios, în loc de o după-amiază calmă.
Du-te și pune la punct mai întâi sandbox-ul. Scrie-mi când ai trecut prin el un card fals refuzat — aceea este versiunea de „funcționează” care chiar contează.
