3DS fallback
Zorg voor transactiecontinuïteit, zelfs wanneer 3D Secure 2. 0 niet beschikbaar is of problemen ondervindt.
Het 3DS fallback-mechanisme van Cardflo schakelt automatisch over naar 3DS 1. 0, waardoor weigeringen die anders zouden optreden, worden voorkomen.
Dit handhaaft de transactiestroom en beveiligt de inkomsten voor verkopers.
- Categorie
- Beveiliging
- Mogelijkheden
- 10
- Beschikbaar op
- Alle abonnementen
Het overzicht
3DS fallback is een noodlogica die wordt gebruikt binnen de betalingsgateway of orkestratielaag om authenticatiefouten te beheren tijdens de 3D Secure 2. 0 (3DS2) handshake.
Hoewel de industrie prioriteit heeft gegeven aan de adoptie van 3DS2 om te voldoen aan de SCA-vereisten onder PSD2, ondersteunen bepaalde regionale uitgevers of oudere bankinfrastructuren de nieuwste protocollen mogelijk nog niet.
Als een initiële 3DS2-aanvraag wordt beantwoord met een technische fout, een time-out of een reactie die aangeeft dat de uitgever niet is ingeschreven, probeert een fallback-mechanisme 3DS1 (Legacy 3D Secure) te initiëren.
Dit proces zorgt ervoor dat de transactie in aanmerking blijft komen voor authenticatie in plaats van standaard te leiden tot een harde weigering.
Door het oudere protocol te proberen, kunnen verkopers nog steeds voldoen aan wettelijke mandaten en een aansprakelijkheidsverschuiving bewerkstelligen, mits de uitgever nog steeds een legacy Access Control Server (ACS) onderhoudt.
Deze secundaire routeringslogica bevindt zich tussen de initiële authenticatieaanvraag en de uiteindelijke autorisatieoproep naar de acquirer.
Hoe het werkt
Initiële 3DS2-versiepoging
De verkoper initieert een transactie via de gateway, die eerst probeert de juiste 3DS2-versie te identificeren die door de uitgever wordt ondersteund. Het systeem analyseert de BIN en de Directory Server-reactie om te bepalen of het nieuwere, frictieloze protocol beschikbaar is voor de specifieke kaarthouder.
Fout- of niet-deelnamedetectie
Als de Directory Server een status retourneert die aangeeft dat de uitgever 3DS2 niet heeft geïmplementeerd, of als er een technische fout optreedt tijdens de versie-uitwisseling, identificeert het systeem dit als een potentieel faalpunt dat zou leiden tot een transactieweigering als het onbehandeld blijft.
Automatische 3DS1-berichtconstructie
De fallback-engine herformateert onmiddellijk de authenticatieaanvraag naar een 3DS1-compatibel bericht. Dit omvat het genereren van de benodigde omleidings-URL's voor de legacy browsergebaseerde uitdaging, zodat de klant wordt overgezet naar de authenticatiepagina van de uitgever zonder een harde annulering van de betalingssessie.
Fallback-authenticatie-uitvoering
De kaarthouder voltooit het legacy-authenticatieproces, meestal met een statisch wachtwoord of een sms-gebaseerde code. Zodra de uitgever de identiteit heeft geverifieerd, verstrekt deze een authenticatiewaarde, zoals een CAVV of AAV, die nodig is voor de daaropvolgende autorisatieaanvraag aan de acquirer.
Autorisatie met legacy-bewijs
De transactie gaat verder naar de acquirer met de 3DS1-authenticatiegegevens. Indien gevalideerd, behoudt de verkoper meestal het voordeel van de aansprakelijkheidsverschuiving, waardoor het bedrijf wordt beschermd tegen fraudegerelateerde chargebacks, ondanks dat de transactie niet via het primaire 3DS2-protocol is verwerkt.
Waarom het telt
Voorkomen van technische weigeringen
Alleen vertrouwen op 3DS2 kan leiden tot onnodige betalingsfouten bij interactie met uitgevers in ontwikkelingsmarkten of die met vertraagde infrastructuurupdates.
Fallback-logica zorgt ervoor dat een gebrek aan moderne protocolondersteuning niet automatisch leidt tot een verloren verkoop, waardoor de conversieratio van de verkoper over diverse kaarthouderbases behouden blijft.
Naleving van regelgeving en beveiliging
In jurisdicties die worden beheerst door PSD2, is authenticatie een wettelijke vereiste voor de meeste externe transacties.
Terugvallen op 3DS1 stelt verkopers in staat om te voldoen aan de Strong Customer Authentication (SCA)-regels wanneer het voorkeurspad van 3DS2 niet beschikbaar is, waardoor het risico op door toezichthouders afgedwongen transactieblokkades of boetes voor niet-naleving wordt vermeden.
Bescherming tegen aansprakelijkheid voor fraude
Een primair voordeel van 3D Secure is de verschuiving van aansprakelijkheid van de verkoper naar de uitgever voor frauduleuze geschillen.
Zonder een fallback-mechanisme zou een verkoper gedwongen kunnen worden een transactie zonder enige authenticatie te verwerken, waardoor hij zichzelf blootstelt aan financieel verlies als de transactie later als ongeautoriseerd wordt betwist.
Toepassingen
Grensoverschrijdende handel
Verkopers die verkopen aan klanten in regio's waar de adoptie van 3DS2 achterblijft bij Europa of Noord-Amerika, gebruiken fallback om succesvolle authenticatiepercentages te handhaven.
Ondersteuning van legacy-uitgevers
Detailhandelaren met een groot transactievolume van kleine regionale banken of kredietverenigingen die nog steeds werken met legacy 3DS1-infrastructuur.
Beveiliging van risicovolle transacties
Bedrijven in risicovolle sectoren gebruiken fallback om ervoor te zorgen dat elke mogelijke authenticatieroute wordt geprobeerd, waardoor de kans op het verkrijgen van een aansprakelijkheidsverschuiving wordt gemaximaliseerd.
Platform- en marktplaatsstabiliteit
Marktplaatsen met diverse sub-verkopers gebruiken fallback om ervoor te zorgen dat verschillende kaarttypen en uitgeversreacties de totale afrekenervaring niet verstoren.
In cijfers
Typische authenticatiesuccespercentages wanneer fallback is ingeschakeld, aangezien het transacties vastlegt van uitgevers die geen moderne protocolondersteuning hebben.
De geschatte afname van technische weigeringen waargenomen door verkopers bij het implementeren van geautomatiseerde versiebeheer en fallback-logica.
De standaard verwerkingsoverhead voor de gateway om protocollen te wisselen, exclusief de tijd die de kaarthouder nodig heeft om interactie te hebben met de uitdaging.
Verwante termen
Talk to our team about a live rollout on your acquiring stack.
Wat u krijgt met 3DS fallback
- Identificeert 2.0 protocolfouten in realtime om onmiddellijk legacy-authenticatiepaden te activeren.
- Omzeilt technische time-outs door indien nodig om te leiden naar stabiele legacy-infrastructuur.
- Handhaaft Strong Customer Authentication-compliance voor EEA- en UK-gereguleerde transacties.
- Legt CAVV- en AAV-waarden vast uit legacy-reacties voor geldige autorisatieverzoeken.
- Ondersteunt zowel Mastercard SecureCode als Verified by Visa legacy-protocolimplementaties.
- Beschermt verkopers tegen fraudegerelateerde chargebacks door consistente toepassing van aansprakelijkheidsverschuiving.
- Analyseert Directory Server-reacties om de hoogst beschikbare protocolversie te bepalen.
- Vermindert het aantal harde weigeringen veroorzaakt door niet-deelname van de uitgever aan 3DS2.
- Assisteert bij wereldwijde expansie door oudere banktechnologie in opkomende markten te ondersteunen.
- Minimaliseert winkelwagenverlating door een alternatieve authenticatieroute te bieden tijdens systeemstoringen.
A short scoping call, then a written plan for your MIDs.
Vragen over 3DS fallback
Is 3DS1 fallback nog steeds compliant met PSD2- en SCA-regelgeving?
Ja, volgens de huidige regelgevende richtlijnen wordt 3DS1 nog steeds beschouwd als een geldige methode voor het uitvoeren van Strong Customer Authentication (SCA) als 3DS2 niet beschikbaar is.
Hoewel toezichthouders en schemes sterk de voorkeur geven aan 3DS2 vanwege de verbeterde gegevensuitwisseling en het mobielgerichte ontwerp, voldoet terugvallen op 3DS1 aan de vereiste voor tweefactorauthenticatie.
Dit zorgt ervoor dat de verkoper geen onbeveiligde transactie hoeft uit te voeren, die waarschijnlijk door een uitgever zou worden geweigerd onder het SCA-mandaat.
Zal het gebruik van 3DS fallback de gebruikerservaring bij het afrekenen beïnvloeden?
3DS1 omvat doorgaans een volledige paginadoorverwijzing of een iframe, wat minder geïntegreerd is dan de frictieloze stroom van 3DS2. Hoewel 3DS2 gegevens-alleen-authenticatie zonder gebruikersinteractie mogelijk maakt, zal een terugval naar 3DS1 bijna altijd vereisen dat de kaarthouder interactie heeft met een uitdagingspagina.
Dit kan lichte frictie introduceren in vergelijking met een succesvolle 3DS2 frictieloze stroom, maar het heeft over het algemeen de voorkeur boven een harde weigering, waardoor de klant de aankoop volledig zou moeten annuleren.
Biedt 3DS fallback dezelfde aansprakelijkheidsverschuiving als 3DS2?
In de meeste gevallen wel. Wanneer een transactie succesvol wordt geauthenticeerd via 3DS1, verschuift de aansprakelijkheid voor fraudegerelateerde geschillen doorgaans van de verkoper naar de uitgever, vergelijkbaar met 3DS2.
Het is echter belangrijk op te merken dat de kaartschemes einddata hebben vastgesteld voor legacy 3DS1-ondersteuning. Naarmate deze data verstrijken, kunnen de voordelen van de aansprakelijkheidsverschuiving voor 3DS1 in bepaalde regio's worden ingetrokken, waardoor het essentieel is om 3DS2 waar mogelijk te prioriteren.
Hoe beslist het systeem wanneer een fallback moet worden geactiveerd?
De fallback wordt geactiveerd op basis van de reactie van de Scheme Directory Server of de Issuer Access Control Server.
Veelvoorkomende triggers zijn een 'Status N' (Niet Ingeschreven) reactie voor 3DS2, een technische foutcode die aangeeft dat de server niet werkt, of een time-out waarbij het 3DS2-versieaanvraag geen reactie ontvangt binnen een ingestelde termijn (vaak 2-5 seconden).
Kan ik 3DS fallback uitschakelen voor specifieke regio's of MCC's?
Ja, betalingsorkestratie-instellingen maken meestal gedetailleerde controle mogelijk.
Een verkoper kan ervoor kiezen om fallback uit te schakelen voor regio's waar 3DS1 volledig is uitgefaseerd of voor specifieke Merchant Category Codes (MCC's) waar de frictie van een legacy-omleiding te hoog wordt geacht in verhouding tot de transactiewaarde.
Voor de meeste Europese verkopers is het echter standaardpraktijk om het ingeschakeld te houden om het succes van autorisaties te maximaliseren.
Wat gebeurt er als zowel 3DS2 als 3DS1 mislukken?
Als beide protocollen mislukken, wordt de transactie doorgaans als 'ongeauthenticeerd' naar de uitgever gestuurd.
Afhankelijk van de risico-instellingen van de verkoper en de regionale regelgeving (zoals SCA), kan de transactie door de gateway worden geweigerd voordat deze de acquirer bereikt, of deze kan worden doorgestuurd naar de uitgever die deze waarschijnlijk zal weigeren met een 'soft decline'-code,
waarbij authenticatie wordt aangevraagd.
Zijn er extra scheme-kosten verbonden aan 3DS fallback?
Scheme-kosten voor 3D Secure worden over het algemeen per authenticatiepoging toegepast. Hoewel er meestal geen specifieke 'fallback-kosten' zijn, blijft de verkoper verantwoordelijk voor de standaard 3DS-onderzoekskosten.
Sommige acquirers kunnen verschillende prijsniveaus hebben voor 3DS2 versus 3DS1, dus het is raadzaam om het interchange-plus of blended prijsplan te controleren op eventuele variaties in verwerkingskosten.
Gerelateerde functies.
Klaar voor snelheid?
Vertel ons over uw bedrijf. Wij matchen u met de juiste acquiring partners en de juiste route, doorgaans binnen een week.