import { loadStripe } from '@stripe/stripe-js';
// Inițializare rapidă pentru Stripe Elements
const stripe = await loadStripe('pk_test_51Nx...');
const options = {
clientSecret: 'pi_3Mtw7gLkdIwHu7ix1_secret_f7y...',
appearance: {
theme: 'flat',
variables: { colorPrimary: '#0070f3' }
}
};
const elements = stripe.elements(options);
const paymentElement = elements.create('payment');
paymentElement.mount('#payment-element');Am implementat ambele variante de plată de la Stripe pe vreo patru proiecte diferite în ultimii ani, inclusiv pe un SaaS românesc unde aveam nevoie de abonamente recurente și facturare pe firmă. Discuția asta dintre Stripe Checkout și Stripe Elements apare la aproape orice kickoff de proiect. Hai să vedem pe scurt cum stă treaba în realitate, fără povești din documentația lor oficială.
Stripe Checkout: Calea rapidă și „safe”
Stripe Checkout înseamnă că trimiți userul pe o pagină găzduită direct de Stripe pentru a finaliza plata.
La un proiect cu vreo 1.200 de useri activi, am pus Checkout pe picioare în fix 3 ore de la zero. Marele avantaj e că Stripe se ocupă de tot ce înseamnă conformitate: 3D Secure (obligatoriu în UE prin SCA), traducerea paginii în funcție de browser, validările de card și design-ul adaptat pentru mobil. Practic, ai zero mentenanță pe partea de frontend de plată.
Trade-off-ul sincer: Utilizatorul pleacă de pe site-ul tău. Dacă vinzi abonamente scumpe sau targetezi clienți enterprise, saltul ăsta de pe domeniul tău pe checkout.stripe.com poate tăia puțin din încredere și strică fluxul de branding. În plus, ești destul de limitat la cum poți customiza pagina respectivă.
Stripe Elements: Control total, dar cu dureri de cap
Cu Elements, construiești formularul direct în site-ul tău folosind componentele lor securizate (iframes). Userul nu pleacă nicăieri.
Arată mult mai profi, poți face fluxuri de checkout într-un singur pas, cu upsell direct în pagină. Dar costul de dezvoltare e mult mai mare. Trebuie să scrii tu logica pentru stările de loading, afișarea erorilor, plus că trebuie să testezi formularul pe zeci de rezoluții de mobil.
Am pățit la un SaaS imobiliar ca un update minor de CSS global să-mi strice layout-ul de Elements pe Safari iOS, fix când omul voia să plătească un abonament de 150 de euro. Am aflat după 3 zile din loguri, când scăzuse conversia cu 20%. Asta e responsabilitatea ta când mergi pe Elements.
Problema cu ANAF și facturarea în România
Aici e buba mare pentru noi. În România, dacă vinzi B2B, ai nevoie obligatoriu de datele fiscale ale clientului (CUI, Reg. Com., Sediu) pentru a emite factura corect prin SmartBill sau FGO.
Cu Stripe Checkout, poți bifa în dashboard să colecteze „tax ID”, dar formularul lor e destul de rigid pentru formatul românesc și nu poți valida CUI-ul în timp real prin API-ul ANAF sau VIES înainte ca omul să plătească.
Dacă mergi pe Stripe Elements, poți pune în stânga formularului de plată câmpurile tale custom pentru CUI și sediu, le validezi frumos cu API-ul tău, iar când totul e verde, trimiți metadatele curate către Stripe ca să poți genera factura corect din webhook.
Concluzia mea
Pentru un MVP sau un SaaS la început de drum, mergi pe Stripe Checkout fără să stai pe gânduri. Economisești cel puțin 3-4 zile de muncă și teste de securitate pe care le poți folosi ca să îmbunătățești produsul.
Treci la Stripe Elements doar când ai deja un volum constant de tranzacții, resurse de design/dev dedicate și ai nevoie neapărat de un flux de facturare B2B ultra-personalizat direct în aplicație.
Voi ce folosiți acum pe proiectele voastre locale? Ați avut probleme cu validarea de TVA la checkout-ul standard de la Stripe?