Checklist inainte de a trece platile pe LIVE: din test mode in productie fara greseli

Ai construit checkout-ul, ai testat cu cardurile de test si totul merge perfect. Apoi apesi butonul "go live" si aici incep problemele reale: plata trece dar banii nu ajung, webhook-ul nu confirma comanda, sau clientul e taxat de doua ori. In test mode nimic din toate astea nu doare. In productie, fiecare greseala e un ban pierdut sau un client suparat.

Diferenta dintre test si live nu e un simplu comutator. Sunt chei diferite, un cont care trebuie verificat complet, webhook-uri separate si o gramada de detalii legale care in Romania sunt obligatorii. Am pus mai jos checklist-ul pe care il parcurgem inainte de fiecare lansare de plati, in ordinea in care conteaza. Nu e teorie: sunt exact lucrurile care se sparg cel mai des.

1. Chei live, cont activat, nimic de test ramas in cod

Prima capcana: cheile. In Stripe (si aproape orice procesator) ai un set de chei de test si un set live, complet separate. Datele nu se transfera intre ele — comenzile, clientii si abonamentele din test nu exista in live.

De verificat:

• Cheia live e in variabile de mediu, NU scrisa direct in cod si NU urcata pe Git.
• Ai inlocuit-o in toate locurile: frontend (cheia publica), backend (cheia secreta), si in orice serviciu conectat.
• Contul e activat complet: date firma, cont bancar pentru payout, verificarea de identitate (KYC) finalizata. Fara asta, poti incasa dar nu poti retrage.
• Ai scos butoanele, produsele si preturile de test din pagina live.

Un singur `sk_test_` uitat inseamna plati care par ca merg, dar nu incaseaza nimic real.

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

Cea mai frecventa greseala la go-live: webhook-ul de test ramane, iar cel de productie lipseste sau are secretul gresit. Rezultatul e brutal — clientul plateste, banii intra la procesator, dar site-ul tau nu afla niciodata, deci comanda ramane neconfirmata.

De verificat:

• Ai creat un endpoint de webhook SEPARAT pentru modul live, cu propriul "signing secret".
• Verifici semnatura fiecarui eveniment inainte sa il procesezi (altfel oricine iti poate falsifica o plata).
• Tratezi evenimentele idempotent: acelasi eveniment poate veni de doua ori, iar codul tau nu trebuie sa trimita comanda de doua ori.
• Te bazezi pe webhook pentru confirmarea finala, nu pe redirect-ul din browser — utilizatorul poate inchide tab-ul inainte sa se intoarca.

Testeaza-l cu o plata reala, nu doar cu simulatorul.

3. Sume, valuta si TVA: greseli care costa bani exact

Majoritatea procesatoarelor lucreaza in cea mai mica unitate a monedei. 100 RON nu se trimite ca "100", ci ca 10000 (bani). E o greseala clasica sa afisezi corect in pagina, dar sa trimiti suma inmultita sau impartita gresit — si abia clientul iti spune ca a fost taxat aiurea.

De verificat:

• Sumele sunt calculate pe server, niciodata luate din pretul trimis de browser (altfel oricine il poate modifica).
• Valuta e corecta si consistenta peste tot (RON, EUR).
• TVA-ul e inclus si afisat clar, iar pretul final din checkout e identic cu cel din pagina de produs.
• Folosesti chei de idempotenta la crearea platii, ca un dublu-click sa nu genereze doua incasari.

O tranzactie de test cu suma reala iti arata imediat daca cifrele se leaga.

4. 3D Secure, SCA si ce se intampla cand plata esueaza

In Romania si in UE, autentificarea puternica (SCA / 3D Secure) e obligatorie pentru majoritatea platilor cu cardul. In test mode, cardurile de test trec de multe ori fara pasul de confirmare de la banca. In productie, clientul real primeste un SMS sau o notificare din aplicatia bancii — iar daca fluxul tau nu gestioneaza acest pas, plata pare ca "se blocheaza".

De verificat:

• Checkout-ul suporta pasul de autentificare 3D Secure si asteapta rezultatul lui.
• Ai stari clare pentru esec: card refuzat, fonduri insuficiente, autentificare abandonata — cu mesaje pe care clientul le intelege.
• Clientul poate reincerca fara sa piarda cosul.
• Refund-ul functioneaza: testeaza-l o data pe bune, ca sa stii cum arata cand chiar ai nevoie de el.

Un checkout fara stari de eroare pierde clienti tacut.

5. Partea legala din Romania: fara ea, plata nu e completa

Un checkout care functioneaza tehnic dar nu are actele la locul lor te expune la reclamatii si amenzi. In Romania, comertul online are cerinte clare.

De verificat:

• Termeni si conditii, Politica de confidentialitate (GDPR) si Politica de retur, accesibile din checkout.
• Preturile afisate cu TVA inclus.
• Datele firmei vizibile (denumire, CUI, sediu, contact).
• Link-ul catre platforma SOL (Solutionarea Online a Litigiilor) si informarea privind ANPC.
• Factura emisa automat dupa plata — in Romania e-Factura devine standardul, deci conecteaza checkout-ul cu un sistem de facturare (de exemplu Oblio) inca de la inceput.

Aceste lucruri par birocratie pana cand primesti prima reclamatie. Le rezolvi o data, corect, si nu te mai gandesti la ele.

6. Testul final: o tranzactie reala, apoi refund

Ultimul pas inainte sa spui ca esti live: fa tu insuti o plata reala, cu cardul tau, cu o suma mica. E singura modalitate prin care vezi tot lantul functionand impreuna — checkout, 3D Secure, webhook, confirmare comanda, email, factura, si banii aparand in contul de payout.

Apoi da refund la aceeasi tranzactie si verifica ca si returul merge curat. Daca toate astea se leaga o data, esti gata.

La MPO Web Studio livram site-uri cu plati integrate remote, in toata tara, si facem exact acest parcurs de go-live impreuna cu clientul — cu un demo gata construit inainte sa platesti ceva. Daca vrei sa trecem checklist-ul asta pe site-ul tau inainte de lansare, scrie-ne pe WhatsApp si il parcurgem pas cu pas.