3DS fallback
Asigură continuitatea tranzacțiilor chiar și atunci când 3D Secure 2. 0 nu este disponibil sau întâmpină probleme.
Mecanismul de fallback 3DS al Cardflo comută automat la 3DS 1. 0, prevenind refuzurile care altfel ar apărea.
Acest lucru menține fluxul tranzacțiilor și asigură veniturile pentru comercianți.
- Categorie
- Securitate
- Capabilități
- 10
- Disponibil pe
- Toate planurile
Prezentarea generală
Fallback-ul 3DS este o logică de contingență utilizată în cadrul gateway-ului de plată sau al stratului de orchestrare pentru a gestiona eșecurile de autentificare în timpul handshake-ului 3D Secure 2. 0 (3DS2).
Deși industria a prioritizat adoptarea 3DS2 pentru a îndeplini cerințele SCA conform PSD2, anumiți emitenți regionali sau infrastructuri bancare mai vechi pot să nu suporte încă cele mai recente protocoale.
Dacă o cerere inițială 3DS2 este întâmpinată cu o eroare tehnică, un timeout sau un răspuns care indică faptul că emitentul nu este înrolat, un mecanism de fallback încearcă să inițieze 3DS1 (Legacy 3D Secure).
Acest proces asigură că tranzacția rămâne eligibilă pentru autentificare, în loc să se ajungă la un refuz dur.
Prin încercarea protocolului mai vechi, comercianții pot îndeplini în continuare mandatele de reglementare și pot asigura un transfer de responsabilitate, cu condiția ca emitentul să mențină încă un Access Control Server (ACS) moștenit.
Această logică de rutare secundară se află între cererea inițială de autentificare și apelul final de autorizare către achizitor.
Cum funcționează
Încercare inițială de versiune 3DS2
Comerciantul inițiază o tranzacție prin gateway, care încearcă mai întâi să identifice versiunea 3DS2 adecvată suportată de emitent. Sistemul analizează BIN-ul și răspunsul serverului de director pentru a determina dacă protocolul mai nou, fără fricțiune, este disponibil pentru deținătorul specific al cardului.
Detectarea erorilor sau a neparticipării
Dacă serverul de director returnează un statut care indică faptul că emitentul nu a implementat 3DS2, sau dacă apare o eroare tehnică în timpul schimbului de versiuni,
sistemul identifică acest lucru ca un punct de eșec potențial care ar duce la un refuz al tranzacției dacă nu este abordat.
Construcția automată a mesajului 3DS1
Motorul de fallback reformatează imediat cererea de autentificare într-un mesaj compatibil 3DS1. Aceasta include generarea URL-urilor de redirecționare necesare pentru provocarea bazată pe browser moștenită, asigurând că clientul este transferat la pagina de autentificare a emitentului fără o abandonare dură a sesiunii de plată.
Execuția autentificării fallback
Deținătorul cardului finalizează procesul de autentificare moștenit, implicând de obicei o parolă statică sau un cod bazat pe SMS.
Odată ce emitentul verifică identitatea, acesta furnizează o valoare de autentificare, cum ar fi un CAVV sau AAV, care este necesară pentru cererea ulterioară de autorizare către achizitor.
Autorizare cu dovadă moștenită
Tranzacția continuă către achizitor cu datele de autentificare 3DS1. Dacă este validată, comerciantul păstrează de obicei beneficiul transferului de responsabilitate, protejând afacerea de chargeback-urile legate de fraudă, în ciuda faptului că tranzacția nu a fost procesată prin protocolul primar 3DS2.
De ce contează
Prevenirea refuzurilor tehnice
Bazarea exclusivă pe 3DS2 poate duce la eșecuri inutile de plată atunci când se interacționează cu emitenți din piețele în curs de dezvoltare sau cu cei cu actualizări întârziate ale infrastructurii.
Logica de fallback asigură că lipsa suportului pentru protocoale moderne nu se traduce automat într-o vânzare pierdută, menținând rata de conversie a comerciantului pe diverse baze de deținători de carduri.
Conformitate și securitate reglementară
În jurisdicțiile guvernate de PSD2, autentificarea este o cerință legală pentru majoritatea tranzacțiilor la distanță.
Revenirea la 3DS1 permite comercianților să rămână conformi cu regulile Strong Customer Authentication (SCA) atunci când calea preferată 3DS2 nu este disponibilă, evitând riscul blocajelor de tranzacții impuse de reglementatori sau amenzilor pentru neconformitate.
Protecție împotriva responsabilității pentru fraudă
Un avantaj principal al 3D Secure este transferul de responsabilitate de la comerciant la emitent pentru disputele frauduloase.
Fără un mecanism de fallback, un comerciant ar putea fi forțat să proceseze o tranzacție fără nicio autentificare, expunându-se la pierderi financiare dacă tranzacția este ulterior contestată ca neautorizată.
Cazuri de utilizare
Comerț transfrontalier
Comercianții care vând clienților din regiuni unde adoptarea 3DS2 este în urmă față de Europa sau America de Nord utilizează fallback-ul pentru a menține rate de autentificare de succes.
Suport pentru emitenți moșteniți
Retaileri cu un volum mare de tranzacții de la bănci regionale mici sau uniuni de credit care operează încă pe infrastructura 3DS1 moștenită.
Securitatea tranzacțiilor cu risc ridicat
Afacerile din sectoarele cu risc ridicat utilizează fallback-ul pentru a se asigura că fiecare cale de autentificare posibilă este încercată, maximizând șansele de a asigura un transfer de responsabilitate.
Stabilitatea platformei și a pieței
Piețele cu sub-comercianți diverși utilizează fallback-ul pentru a se asigura că tipurile variate de carduri și răspunsurile emitenților nu perturbă experiența agregată de finalizare a comenzii.
În cifre
Rate tipice de succes ale autentificării atunci când fallback-ul este activat, deoarece captează tranzacții de la emitenți care nu dispun de suport pentru protocoale moderne.
Scăderea estimată a refuzurilor tehnice observată de comercianți la implementarea logicii automate de versiune și fallback.
Costul standard de procesare pentru gateway de a schimba protocoalele, excluzând timpul necesar deținătorului cardului pentru a interacționa cu provocarea.
Termeni asociați
Talk to our team about a live rollout on your acquiring stack.
Ce obțineți cu 3DS fallback
- Identifică în timp real erorile protocolului 2.0 pentru a declanșa imediat căi de autentificare moștenite.
- Ocolește timpii de expirare tehnici prin redirecționarea către infrastructura moștenită stabilă atunci când este necesar.
- Menține conformitatea cu Strong Customer Authentication pentru tranzacțiile reglementate în SEE și Marea Britanie.
- Capturează valorile CAVV și AAV din răspunsurile moștenite pentru cererile de autorizare valide.
- Suportă implementările protocolului moștenit atât Mastercard SecureCode, cât și Verified by Visa.
- Protejează comercianții de chargeback-urile legate de fraudă prin aplicarea consecventă a transferului de responsabilitate.
- Analizează răspunsurile serverului de director pentru a determina cea mai înaltă versiune de protocol disponibilă.
- Reduce volumul refuzurilor dure cauzate de neparticiparea emitentului la 3DS2.
- Ajută la extinderea globală prin suportul tehnologiei bancare mai vechi pe piețele emergente.
- Minimizează abandonul coșului de cumpărături oferind o rută alternativă de autentificare în timpul întreruperilor de sistem.
A short scoping call, then a written plan for your MIDs.
Întrebări despre 3DS fallback
Este fallback-ul 3DS1 încă conform cu reglementările PSD2 și SCA?
Da, conform ghidurilor de reglementare actuale, 3DS1 este încă considerată o metodă validă pentru efectuarea Strong Customer Authentication (SCA) dacă 3DS2 nu este disponibil.
Deși autoritățile de reglementare și schemele preferă puternic 3DS2 datorită partajării îmbunătățite a datelor și designului centrat pe mobil, revenirea la 3DS1 satisface cerința pentru autentificarea cu doi factori.
Acest lucru asigură că comerciantul nu trebuie să recurgă la o tranzacție neautentificată, care ar fi probabil refuzată de un emitent conform mandatului SCA.
Va afecta utilizarea fallback-ului 3DS experiența utilizatorului la finalizarea comenzii?
3DS1 implică de obicei o redirecționare pe pagină completă sau un iframe, care este mai puțin integrat decât fluxul fără fricțiune al 3DS2.
În timp ce 3DS2 permite autentificarea doar a datelor fără interacțiunea utilizatorului, o revenire la 3DS1 va necesita aproape întotdeauna ca deținătorul cardului să interacționeze cu o pagină de provocare.
Acest lucru poate introduce o ușoară fricțiune în comparație cu un flux fără fricțiune 3DS2 de succes, dar este, în general, preferat în detrimentul unui refuz dur, care ar necesita ca clientul să abandoneze complet achiziția.
Oferă fallback-ul 3DS același transfer de responsabilitate ca și 3DS2?
În majoritatea cazurilor, da. Atunci când o tranzacție este autentificată cu succes prin 3DS1, transferul de responsabilitate pentru disputele legate de fraudă se mută de obicei de la comerciant la emitent, similar cu 3DS2.
Cu toate acestea, este important de reținut că schemele de carduri au stabilit date de încetare a suportului pentru 3DS1 moștenit.
Pe măsură ce aceste date trec, beneficiile transferului de responsabilitate pentru 3DS1 pot fi retrase în anumite regiuni, făcând esențială prioritizarea 3DS2 ori de câte ori este posibil.
Cum decide sistemul când să declanșeze un fallback?
Fallback-ul este declanșat pe baza răspunsului de la Scheme Directory Server sau Issuer Access Control Server.
Declanșatorii comuni includ un răspuns 'Status N' (Neînrolat) pentru 3DS2, un cod de eroare tehnic care indică faptul că serverul este oprit sau un timeout în care cererea de versiune 3DS2 nu primește un răspuns într-un interval de timp stabilit (adesea 2-5 secunde).
Pot dezactiva fallback-ul 3DS pentru anumite regiuni sau MCC-uri?
Da, setările de orchestrare a plăților permit de obicei un control granular.
Un comerciant ar putea alege să dezactiveze fallback-ul pentru regiunile în care 3DS1 este complet dezafectat sau pentru anumite coduri de categorie de comerciant (MCC) unde fricțiunea unei redirecționări moștenite este considerată prea mare în raport cu valoarea tranzacției.
Cu toate acestea, pentru majoritatea comercianților europeni, menținerea activată este o practică standard pentru a maximiza succesul autorizării.
Ce se întâmplă dacă atât 3DS2, cât și 3DS1 eșuează?
Dacă ambele protocoale eșuează, tranzacția va fi trimisă de obicei emitentului ca 'neautentificată'.
În funcție de setările de risc ale comerciantului și de reglementările regionale (cum ar fi SCA), tranzacția poate fi refuzată de gateway înainte de a ajunge la achizitor, sau poate fi transmisă emitentului care o va refuza probabil cu un cod de 'refuz soft',
solicitând autentificarea.
Există taxe suplimentare de schemă asociate cu fallback-ul 3DS?
Taxele de schemă pentru 3D Secure sunt, în general, aplicate per încercare de autentificare. Deși de obicei nu există o 'taxă de fallback' specifică, comerciantul va rămâne responsabil pentru taxele standard de interogare 3DS.
Unii achizitori pot avea niveluri de preț diferite pentru 3DS2 față de 3DS1, așa că este recomandabil să verificați programul de prețuri interchange-plus sau blended pentru orice variații ale costurilor de procesare.
Funcționalități similare.
Ești pregătit pentru viteză?
Spuneți-ne despre afacerea dvs. Vă vom potrivi cu partenerii de achiziție potriviți și cu ruta corectă, de obicei în mai puțin de o săptămână.