const stripe = require('stripe')('sk_test_123');
// Exemplu rapid de Stripe Checkout Session (varianta simplă)
const session = await stripe.checkout.sessions.create({
payment_method_types: ['card'],
line_items: [{
price: 'price_H5ggYwtHuqnH8b', // ID-ul planului din Stripe
quantity: 1,
}],
mode: 'subscription',
tax_id_collection: {
enabled: true, // Colectează CUI-ul automat, dar prin validare VIES
},
success_url: 'https://mysaas.ro/success?session_id={CHECKOUT_SESSION_ID}',
cancel_url: 'https://mysaas.ro/pricing',
});Zilele trecute m-a întrebat un fost coleg ce să aleagă pentru plata unui MVP de SaaS pe nișa de HR din România. Răspunsul meu scurt e mereu același: începe cu Checkout, treci la Elements doar când ai buget de aruncat pe design și optimizări fine. Ambele soluții sunt excelente, dar ascund niște capcane de implementare de care te lovești abia după ce ai primii clienți care vor factură pe firmă.
Am lucrat la proiecte unde am trecut de la una la alta și am văzut exact unde se rupe filmul.
Stripe Checkout: Varianta rapidă (și un pic rigidă)
La un proiect SaaS cu aproximativ 1.200 de useri activi, am mers exclusiv pe Stripe Checkout. Am scris codul de backend în două ore, am configurat webhook-urile și gata, încasam bani. Stripe îți pune la dispoziție o pagină găzduită de ei, optimizată la sânge pentru conversii.
Cel mai mare avantaj? Se ocupă singuri de tot ce înseamnă conformitate fiscală, Apple Pay, Google Pay și, mai ales, de autentificarea 3D Secure (SCA), care în Europa e obligatorie și dă mari bătăi de cap la implementările custom.
Trade-off-ul sincer este pierderea controlului pe UX. Userul este redirectat de pe site-ul tău pe domeniul Stripe. Dacă rulezi campanii de marketing cu Facebook Pixel sau Google Ads, tracking-ul conversiilor devine o mică durere de cap fiindcă redirect-ul ăla poate strica uneori sesiunile de tracking în analytics.
Stripe Elements: Control total, dar costuri de dev pe măsură
Pe de altă parte, am avut un client cu un SaaS B2B destul de mare, unde userii trebuiau să își configureze spațiul de lucru în timp ce introduceau cardul. Nu puteam să-i scoatem din aplicație. Am folosit Stripe Elements, care îți oferă seturi de input-uri securizate (iframes) pe care le poți stiliza direct în CSS-ul tău.
UX-ul a ieșit impecabil. Totul se simțea nativ, integrat în onboarding-ul nostru în trei pași.
Dar costul de development a fost uriaș. Am pierdut vreo două săptămâni doar testând cazurile de eroare: ce se întâmplă când cardul e expirat, când banca cere confirmare în aplicație (SCA) și cum randezi corect modala de autentificare fără să strici layout-ul paginii. Pe scurt, scrii de trei ori mai mult cod pentru a gestiona stările de loading și erorile de rețea.
Specificul de România: CUI-ul și facturarea fiscală
Dacă vinzi către firme din România (B2B), ai nevoie de CUI/CIF pentru facturare.
În Stripe Checkout, poți bifa opțiunea de a colecta "Tax ID", dar Stripe folosește sistemul VIES pentru validare. Dacă o firmă românească nu este înregistrată în scopuri de TVA intracomunitar (deci nu e în VIES, deși e firmă activă), Stripe Checkout s-ar putea să o respingă sau să nu-i aplice corect taxele, forțând userul să introducă datele manual.
Cu Stripe Elements, ai control total. Poți pune un input custom de CUI în formularul tău, tragi datele firmei în timp real din API-ul ANAF, le validezi, emiți factura automat prin SmartBill sau Factual și abia apoi trimiți tokenul de plată către Stripe. Este de zece ori mai curat pentru contabilitatea de la noi.
Decizia e simplă: dacă ești la început, bootstrapped sau ai o echipă mică, mergi pe Stripe Checkout. Câștigi timp prețios. Dacă ai deja tracțiune, buget de dev și vrei să storci acel 2% în plus la rata de conversie printr-un checkout integrat nativ, treci pe Elements.