De ce eșuează plățile cu cardul pe site-ul tău: erori 3D Secure / SCA și cum le rezolvi

Eroarea „3D Secure failed” sau „autentificare 3D Secure eșuată” înseamnă că pasul de confirmare cerut de banca clientului (aprobarea în aplicația băncii, codul primit prin SMS sau amprenta) nu s-a încheiat. Nu e un refuz pentru lipsă de bani și rareori înseamnă că site-ul e stricat: de obicei clientul n-a aprobat la timp sau n-a primit cererea, iar mai rar o integrare de plată veche nu reușește să afișeze fereastra băncii. Mai jos vezi cum deosebești cele două situații din panoul procesatorului și ce repari tu, respectiv ce repară dezvoltatorul.

Scenariul e cunoscut: clientul adaugă produse în coș, ajunge la plată și acolo se oprește totul. Cardul e refuzat, apare un ecran ciudat de la bancă sau pagina rămâne blocată pe un mesaj de eroare. E frustrant, pentru că marfa era ca și vândută. Odată ce înțelegi ce se întâmplă în cele câteva secunde dintre „Plătește” și „Mulțumim pentru comandă”, majoritatea erorilor devin ușor de diagnosticat.

Ce este 3D Secure / SCA, pe scurt

SCA (Strong Customer Authentication, autentificarea strictă a clientului) e regula europeană introdusă prin directiva PSD2 și aplicată din 14 septembrie 2019. La plățile online cu cardul din Spațiul Economic European, banca trebuie să confirme că plătește chiar titularul cardului, folosind cel puțin doi din trei factori: ceva ce știi (PIN, parolă), ceva ce ai (telefonul) și ceva ce ești (amprentă, recunoaștere facială). În România, băncile aplică regula la plățile online cu cardul de la 1 ianuarie 2021.

3D Secure e mecanismul prin care se face verificarea. Îl întâlnești sub numele Visa Secure, Mastercard Identity Check sau American Express SafeKey. Versiunea actuală, 3DS2, trimite băncii date despre dispozitiv și tranzacție, iar banca poate aproba plata fără nicio întrebare (flux „frictionless”) sau poate cere o confirmare explicită (flux „challenge”). Versiunea veche, 3D Secure 1, nu mai e acceptată de marile rețele de carduri, așa că o integrare rămasă pe ea va genera refuzuri.

Când pasul ăsta merge, clientul abia îl observă. Când ceva e prost configurat, apar refuzuri, pagini albe sau bucle infinite.

Nu orice plată cere confirmare: excepțiile SCA

Mulți comercianți se întreabă de ce un client primește cerere de confirmare și altul nu. Regulile SCA au câteva excepții, pe care procesatorul le poate solicita:

• Plăți mici: sub 30 € pot fi scutite, dar banca cere din nou autentificare după cinci plăți scutite sau dacă suma lor depășește 100 € de la ultima autentificare reușită.
• Analiza riscului tranzacției: procesatorul poate cere scutire pentru plățile considerate cu risc scăzut, în limitele permise de rata lui de fraudă.
• Abonamente cu sumă fixă: prima plată se autentifică, următoarele pot fi scutite.
• Plăți inițiate de comerciant: încasările cu un card salvat, când clientul nu e prezent, sunt tehnic în afara SCA, dacă cardul a fost autentificat corect la salvare.
• Beneficiari de încredere: dacă banca lui oferă opțiunea, clientul îți poate adăuga magazinul pe o listă de încredere.

Important: procesatorul cere excepția, dar decizia finală o ia banca clientului. De aceea două comenzi asemănătoare pot avea parcursuri diferite, iar integrarea ta trebuie să poată afișa oricând fereastra de confirmare.

Cele mai frecvente cauze, pe surse

Primul pas e să separi problemele care țin de client de cele care țin de bancă și de cele care țin de site-ul tău.

La client:

• N-a aprobat la timp: cererea din aplicația băncii sau codul SMS au o durată limitată, iar după expirare plata cade.
• Are notificările oprite, aplicația băncii neinstalată sau neactualizată, ori un număr de telefon vechi înregistrat la bancă.
• A închis fereastra băncii, a apăsat „Anulează” sau a greșit codul de mai multe ori.
• Un pop-up blocker sau un ad-blocker agresiv taie fereastra 3D Secure; un VPN poate declanșa verificări suplimentare la bancă.

La bancă:

• Cardul nu e înrolat în 3D Secure (serviciul nu a fost activat pentru acel card) ori nu e activat pentru plăți online.
• Serverul de autentificare al băncii e temporar indisponibil.
• Banca refuză tranzacția pe criterii proprii de risc.

La site:

• Integrarea e veche: folosește 3D Secure 1 sau un API depășit (la Stripe, vechiul Charges API, despre care Stripe avertizează că poate avea multe refuzuri la băncile care aplică SCA).
• Fereastra băncii nu se poate afișa: o politică de securitate a conținutului (Content Security Policy) prea strictă, un iframe cu atributul sandbox sau un plugin de securitate care blochează domeniile procesatorului.
• Întoarcerea de la bancă nu e tratată: pagina rămâne blocată, iar comanda stă la nesfârșit „în așteptare”.
• Plățile cu card salvat (abonamente, plăți ulterioare) sunt încercate fără ca respectivul card să fi fost autentificat la salvare.

Cum diagnostichezi problema pas cu pas

Nu ghici. Deschide tranzacțiile eșuate în panoul procesatorului (Stripe, NETOPIA, PayU, EuPlătesc etc.) și citește motivul exact. În Stripe, mergi la Transactions > Payments și alege din filtrul de status: „Incomplete” pentru plățile făcute cu clientul prezent care nu s-au încheiat (de obicei rămase la autentificare), „Failed” pentru plățile refuzate cu un card salvat, fără clientul de față. Motivul apare când treci cu mouse-ul peste eticheta de status.

Apoi caută tiparul. Vin toate eșecurile de la aceeași bancă? Doar de pe telefon? Doar din linkuri deschise din Instagram sau Facebook? Dacă problemele sunt concentrate la o singură bancă, probabil ține de acea bancă (o problemă temporară sau o setare a cardurilor ei); dacă vin de peste tot, uită-te la integrare.

La final, testează tu fluxul. În modul de test, procesatorii au carduri care forțează pasul 3D Secure (la Stripe, 4000 0000 0000 3220 cere mereu autentificare), unde poți simula și succesul, și eșecul. Apoi încearcă un card real, pe telefon și pe desktop. Dacă ție îți merge dar clienților nu, problema e adesea la dispozitivul, banca sau rețeaua lor. Dacă nu merge nici ție, e configurare. Pentru restul cauzelor care pot bloca o plată, nu doar 3D Secure, vezi și ghidul despre ce faci când clienții spun că nu pot plăti pe site.

Un detaliu util: la refuzurile marcate ca suspiciune de fraudă sau card furat, Stripe recomandă să nu-i arăți clientului motivul exact, ci un mesaj generic de refuz.

Pentru dezvoltator: ce spune răspunsul 3D Secure

Unii procesatori afișează în detaliile tranzacției câmpurile standard EMV 3-D Secure, care arată unde s-a rupt autentificarea. La alții le poți cere de la suport. Cele mai utile valori:

Ce trebuie verificat în cod:

• Folosește API-ul actual al procesatorului, compatibil SCA (la Stripe: Payment Intents, Checkout sau Payment Element), și ține plugin-ul de plată actualizat.
• Tratează starea în care plata cere o acțiune suplimentară (la Stripe, statusul requires_action): afișează fereastra băncii într-un modal, iframe sau prin redirecționare cu return_url, apoi verifică din nou statusul plății după revenire.
• Permite în Content Security Policy domeniile procesatorului (la Stripe: js.stripe.com, hooks.stripe.com și domeniul adresei de return_url) și nu pune atributul sandbox pe iframe-ul 3D Secure, pentru că paginile unor bănci nu funcționează în acest mod.
• Confirmă comanda pe baza notificării trimise de procesator pe server (webhook sau IPN), nu doar pe baza revenirii în browser. Altfel, clientul care închide tabul după plată rămâne cu banii luați și cu comanda „în așteptare”.
• La abonamente, autentifică cardul în momentul salvării și pregătește un traseu prin care clientul revine să confirme dacă banca cere din nou autentificare. Detaliile sunt în articolul despre recuperarea plăților eșuate la abonamente.

De ce eșuează mai des pe telefon

Pe mobil, pasul 3D Secure are mai multe puncte în care se poate rupe:

• Clientul iese din browser ca să aprobe în aplicația băncii. La întoarcere, unele telefoane au reîncărcat sau închis pagina, iar dacă site-ul se bazează doar pe revenirea în browser, comanda se pierde.
• Browserele integrate în aplicații (când clientul deschide magazinul dintr-un link din Instagram, Facebook sau TikTok) gestionează uneori prost ferestrele noi și redirecționările. Dacă vezi că eșecurile vin de acolo, testează exact acel traseu.
• Notificările aplicației bancare sunt oprite sau întârziate de modul de economisire a bateriei, iar semnalul slab face ca codul SMS să ajungă prea târziu.
• Apple Pay și Google Pay sunt o alternativă bună pe telefon: clientul confirmă plata cu amprenta, Face ID sau codul telefonului, iar plățile din portofelele digitale de obicei nu deschid fereastra 3D Secure clasică.

Ce poți repara singur și ce ține de dezvoltator

Fără programator poți:

• Să adaugi un text scurt la checkout: „Vei primi o cerere de confirmare în aplicația băncii. Aprob-o, apoi revino în această pagină ca să finalizezi comanda.” Mulți clienți abandonează pur și simplu pentru că nu înțeleg ecranul băncii.
• Să oferi o metodă alternativă de plată (Apple Pay sau Google Pay, transfer bancar, ramburs) pentru cei cărora 3D Secure le dă bătăi de cap.
• Să verifici că plugin-ul sau modulul de plată e la ultima versiune și că procesatorul îți confirmă folosirea 3D Secure 2.
• Să pui în pagina de ajutor pașii de mai jos, pentru clienții care se blochează.

Ce ține de dezvoltator: actualizarea integrării, trecerea la API-ul curent al procesatorului, afișarea corectă a ferestrei băncii, tratarea revenirii după autentificare și confirmarea comenzii prin webhook. Dacă pagina se blochează fix după fereastra băncii, aproape sigur e cod care nu tratează răspunsul venit de la 3D Secure.

Un lucru pe care nu-l poți face: să oprești 3D Secure ca să scapi de refuzuri. Stripe, de exemplu, nu permite dezactivarea manuală prin API, iar majoritatea băncilor nu le permit nici clienților să-l dezactiveze complet.

Dacă ești cel care plătește: ce să încerci

Poți copia lista asta în pagina de ajutor a magazinului:

• Reîncearcă plata o dată. Adesea cauza a fost doar expirarea timpului de confirmare.
• Verifică dacă aplicația băncii e actualizată și are notificările pornite și dacă numărul de telefon înregistrat la bancă e cel corect.
• Oprește temporar ad-blocker-ul și VPN-ul și deschide magazinul în Chrome, Safari sau Firefox, nu în browserul din Instagram sau Facebook.
• Verifică în aplicația băncii dacă plățile online sunt activate pe card și dacă limitele permit suma.
• Dacă eroarea se repetă, sună la bancă sau folosește alt card ori altă metodă de plată.

Cum abordăm plățile la MPO Web Studio

Când construim un magazin, tratăm plata ca partea cea mai sensibilă a site-ului, pentru că acolo se câștigă sau se pierde banul. Folosim procesatori care suportă nativ 3D Secure 2, confirmăm comenzile prin notificările de pe server, testăm fluxul pe telefon și pe desktop înainte de lansare și adăugăm mesajele care ghidează clientul prin pasul de confirmare al băncii.

Lucrăm integral remote, pentru clienți din toată țara, și îți pregătim un demo gratuit înainte să plătești ceva, inclusiv fluxul de checkout, ca să vezi cum se comportă.

Dacă pierzi comenzi la plată și nu-ți dai seama de ce, scrie-ne pe WhatsApp cu un exemplu de eroare din panoul procesatorului. Ne uităm împreună și îți spunem cinstit dacă e ceva ce repari tu în cinci minute sau ceva ce ține de integrare.