Checklist înainte de a trece plățile pe LIVE: din test mode în producție fără greșeli

Ai construit checkout-ul, ai testat cu cardurile de test și totul merge perfect. Apoi apeși butonul "go live" și aici încep problemele reale: plata trece dar banii nu ajung, webhook-ul nu confirma comanda, sau clientul e taxat de două ori. În test mode nimic din toate astea nu doare. În productie, fiecare greseala e un ban pierdut sau un client supărat.

Diferența dintre test și live nu e un simplu comutator. Sunt chei diferite, un cont care trebuie verificat complet, webhook-uri separate și o grămadă de detalii legale care în România sunt obligatorii. Am pus mai jos checklist-ul pe care îl parcurgem înainte de fiecare lansare de plăți, în ordinea în care contează. Nu e teorie: sunt exact lucrurile care se sparg cel mai des.

1. Chei live, cont activat, nimic de test rămas în cod

Prima capcana: cheile. În Stripe (și aproape orice procesator) ai un set de chei de test și un set live, complet separate. Datele nu se transferă între ele — comenzile, clienții și abonamentele din test nu există în live.

De verificat:

• Cheia live e în variabile de mediu, NU scrisă direct în cod și NU urcată pe Git.
• Ai înlocuit-o în toate locurile: frontend (cheia publica), backend (cheia secreta), și în orice serviciu conectat.
• Contul e activat complet: date firma, cont bancar pentru payout, verificarea de identitate (KYC) finalizata. Fără asta, poți încasa dar nu poți retrage.
• Ai scos butoanele, produsele și prețurile de test din pagina live.

Un singur `sk_test_` uitat înseamnă plati care par ca merg, dar nu încasează nimic real.

2. Webhook-urile: aici se sparg cele mai multe plati

Cea mai frecventă greseala la go-live: webhook-ul de test rămâne, iar cel de producție lipsește sau are secretul greșit. Rezultatul e brutal — clientul plătește, banii intră la procesator, dar site-ul tău nu află niciodată, deci comanda rămâne neconfirmata.

De verificat:

• Ai creat un endpoint de webhook SEPARAT pentru modul live, cu propriul "signing secret".
• Verifici semnatura fiecărui eveniment înainte să îl procesezi (altfel oricine îți poate falsifica o plată).
• Tratezi evenimentele idempotent: același eveniment poate veni de două ori, iar codul tău nu trebuie să trimită comanda de două ori.
• Te bazezi pe webhook pentru confirmarea finală, nu pe redirect-ul din browser — utilizatorul poate închide tab-ul înainte să se intoarca.

Testează-l cu o plată reală, nu doar cu simulatorul.

3. Sume, valută și TVA: greșeli care costă bani exact

Majoritatea procesatoarelor lucrează în cea mai mică unitate a monedei. 100 RON nu se trimite ca "100", ci ca 10000 (bani). E o greseala clasică să afișezi corect în pagina, dar să trimiți suma inmultita sau împărțită greșit — și abia clientul îți spune că a fost taxat aiurea.

De verificat:

• Sumele sunt calculate pe server, niciodată luate din prețul trimis de browser (altfel oricine îl poate modifica).
• Valută e corectă și consistenta peste tot (RON, EUR).
• TVA-ul e inclus și afișat clar, iar prețul final din checkout e identic cu cel din pagina de produs.
• Folosești chei de idempotenta la crearea plății, ca un dublu-click să nu genereze doua încasări.

O tranzacție de test cu suma reală îți arată imediat dacă cifrele se leagă.

4. 3D Secure, SCA și ce se întâmplă când plata eșuează

În România și în UE, autentificarea puternică (SCA / 3D Secure) e obligatorie pentru majoritatea plăților cu cardul. În test mode, cardurile de test trec de multe ori fără pasul de confirmare de la bancă. În productie, clientul real primește un SMS sau o notificare din aplicația băncii — iar dacă fluxul tău nu gestionează acest pas, plata pare că "se blochează".

De verificat:

• Checkout-ul suportă pasul de autentificare 3D Secure și așteaptă rezultatul lui.
• Ai stări clare pentru eșec: card refuzat, fonduri insuficiente, autentificare abandonată — cu mesaje pe care clientul le înțelege.
• Clientul poate reincerca fără să piardă coșul.
• Refund-ul funcționează: testează-l o data pe bune, ca să știi cum arată când chiar ai nevoie de el.

Un checkout fără stări de eroare pierde clienți tăcut.

5. Partea legală din România: fără ea, plată nu e completă

Un checkout care funcționează tehnic dar nu are actele la locul lor te expune la reclamatii și amenzi. În România, comerțul online are cerințe clare.

De verificat:

• Termeni și condiții, Politica de confidențialitate (GDPR) și Politica de retur, accesibile din checkout.
• Prețurile afișate cu TVA inclus.
• Datele firmei vizibile (denumire, CUI, sediu, contact).
• Link-ul către platforma SOL (Soluționarea Online a Litigiilor) și informarea privind ANPC.
• Factura emisa automat după plată — în România e-Factura devine standardul, deci conectează checkout-ul cu un sistem de facturare (de exemplu Oblio) încă de la început.

Aceste lucruri par birocrație până când primești prima reclamație. Le rezolvi o data, corect, și nu te mai gândești la ele.

6. Testul final: o tranzacție reală, apoi refund

Ultimul pas înainte să spui că ești live: fa tu însuți o plată reală, cu cardul tău, cu o sumă mică. E singura modalitate prin care vezi tot lanțul funcționând împreună — checkout, 3D Secure, webhook, confirmare comanda, email, factură, și banii aparand în contul de payout.

Apoi da refund la aceeași tranzacție și verifică ca și returul merge curat. Dacă toate astea se leagă o data, ești gata.

La MPO Web Studio livrăm site-uri cu plăți integrate remote, în toată țara, și facem exact acest parcurs de go-live împreună cu clientul — cu un demo gata construit înainte să plătești ceva. Dacă vrei să trecem checklist-ul asta pe site-ul tău înainte de lansare, scrie-ne pe WhatsApp și îl parcurgem pas cu pas.