const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);
// Creare sesiune de checkout care colectează automat datele de facturare pentru RO
const session = await stripe.checkout.sessions.create({
payment_method_types: ['card'],
line_items: [{ price: 'price_12345', quantity: 1 }],
mode: 'subscription',
tax_id_collection: { enabled: true }, // Colectează CUI/CIF automat
billing_address_collection: 'required', // Obligatoriu pentru e-Factura
success_url: 'https://saas.ro/success?session_id={CHECKOUT_SESSION_ID}',
cancel_url: 'https://saas.ro/cancel',
});Salutare! Am integrat Stripe în vreo 5 SaaS-uri românești în ultimii ani. Am trecut și prin coșmarul customizării cu Elements, dar și prin simplitatea plictisitoare a lui Checkout. Dacă ești la început cu un SaaS în RO sau vrei să refaci flow-ul de plată, alegerea asta îți poate salva două săptămâni de muncă sau, din contră, îți poate dubla timpul de livrare.
Hai să le luăm la bani mărunți, cu bune și rele.
Stripe Checkout: Calea rapidă (și de ce o recomand în 90% din cazuri)
Stripe Checkout înseamnă că trimiți userul pe o pagină găzduită de Stripe pentru plată. Sună leneș, dar am economisit cam 30% din timpul de development la ultimul proiect (un SaaS B2B cu 1.2k useri) doar pentru că am mers pe ruta asta.
De ce e pont pentru România? Din cauza birocrației noastre. Ca să emiți o factură fiscală legală în RO (și mai nou e-Factura), ai nevoie de date curate: CUI/CIF pentru firme, adresă completă pentru persoane fizice. În Stripe Checkout bifezi o opțiune în dashboard și Stripe colectează automat codul de TVA (Tax ID) și adresa, validându-le formatul local.
Trade-off-ul sincer: Userul părăsește site-ul tău. Dacă vinzi servicii de branding premium, redirectul ăla spre checkout.stripe.com poate părea puțin neprofesionist. Dar pentru un SaaS tehnic sau B2B, nimănui nu-i pasă. Ba chiar oferă un plus de încredere pentru că românii recunosc brandingul Stripe.
Stripe Elements: Când vrei să fii "fancy" și ai timp de pierdut
Elements îți dă niște inputuri gata securizate pe care le pui direct în formularul tău din React, Vue sau ce mai folosești. Userul nu pleacă niciodată de pe site-ul tău. UX-ul e impecabil, totul e integrat în design-ul tău.
Dar aici începe distracția. Am pățit pe un proiect de e-learning să integrăm Elements și să ne lovim de 3D Secure (SCA). În teorie, Stripe se ocupă. În practică, trebuie să scrii tu logica de frontend care prinde eroarea de autentificare, deschide modalul băncii (BT, BCR, ING au implementări destul de dubioase uneori pe mobil) și confirmă plata. Dacă uiți un edge-case în JS, plata eșuează silențios și pierzi clientul.
Plus că trebuie să construiești tu manual toate câmpurile de adresă, selectorul de țară, inputul de CUI și să le validezi înainte să trimiți token-ul la Stripe. Asta înseamnă ore bune de QA pe diverse rezoluții și browsere.
Problema cu e-Factura și ANAF
Indiferent ce alegi, în România ai nevoie de datele de facturare în baza de date ca să le trimiți în ERP sau softul de facturare (SmartBill, Factual etc.).
Dacă folosești Checkout, asculți de webhook-ul checkout.session.completed și extragi de acolo customer_details.tax_ids și adresa. E simplu și curat.
Dacă mergi pe Elements, trebuie să salvezi tu aceste date în baza ta de date înainte de plată sau în timpul ei, legându-le de PaymentIntent. E mult mai mult boilerplate code de scris și de întreținut.
Ce alegi până la urmă?
Regula mea de aur e simplă. Ești la început, validezi ideea sau ai resurse limitate? Mergi pe Stripe Checkout. Îl pui în picioare într-o zi, cu tot cu webhook-uri.
Ai deja tracțiune, vrei să optimizezi conversia cu 1-2%, ai design custom și un dev dedicat care să bibilească JS-ul pentru erori de plată? Treci pe Stripe Elements.
Voi ce folosiți la proiectele voastre din RO? V-ați lovit de probleme cu plățile recurente blocate de băncile de la noi?