3DS връщане към по-стара версия
Осигурете непрекъснатост на трансакциите дори когато 3D Secure 2. 0 е недостъпен или среща проблеми.
Механизмът за 3DS връщане към по-стара версия на Cardflo автоматично преминава към 3DS 1. 0, предотвратявайки откази, които иначе биха възникнали.
Това поддържа потока на трансакциите и осигурява приходи за търговците.
- Категория
- Сигурност
- Възможности
- 10
- Налично на
- Всички планове
Общ преглед
3DS fallback is a contingency logic used within the payment gateway or orchestration layer to manage authentication failures during the 3D Secure 2. 0 (3DS2) handshake.
While the industry has prioritised the adoption of 3DS2 to meet SCA requirements under PSD2, certain regional issuers or older banking infrastructures may not yet support the latest protocols.
If an initial 3DS2 request is met with a technical error, a timeout, or a response indicating the issuer is not enrolled, a fallback mechanism attempts to initiate 3DS1 (Legacy 3D Secure).
This process ensures that the transaction remains eligible for authentication rather than defaulting to a hard decline. By attempting the older protocol, merchants can still satisfy regulatory mandates and secure a liability shift, provided the issuer still maintains a legacy Access Control Server (ACS).
This secondary routing logic sits between the initial authentication request and the final authorisation call to the acquirer.
Как работи
Initial 3DS2 versioning attempt
The merchant initiates a transaction through the gateway, which first attempts to identify the appropriate 3DS2 version supported by the issuer. The system analyses the BIN and the Directory Server response to determine if the newer, frictionless protocol is available for the specific cardholder.
Error or non-participation detection
If the Directory Server returns a status indicating that the issuer has not implemented 3DS2, or if a technical error occurs during the versioning exchange, the system identifies this as a potential failure point that would lead to a transaction refusal if left unaddressed.
Automatic 3DS1 message construction
The fallback engine immediately reformats the authentication request into a 3DS1-compliant message. This includes generating the necessary redirect URLs for the legacy browser-based challenge, ensuring the customer is transitioned to the issuer authentication page without a hard abandonment of the payment session.
Fallback authentication execution
The cardholder completes the legacy authentication process, typically involving a static password or an SMS-based code. Once the issuer verifies the identity, they provide an authentication value, such as a CAVV or AAV, which is necessary for the subsequent authorisation request to the acquirer.
Authorisation with legacy proof
The transaction proceeds to the acquirer with the 3DS1 authentication data. If validated, the merchant usually retains the benefit of the liability shift, protecting the business from fraud-related chargebacks despite the transaction not being processed via the primary 3DS2 protocol.
Защо е важно
Prevention of technical declines
Relying solely on 3DS2 can lead to unnecessary payment failures when interacting with issuers in developing markets or those with delayed infrastructure updates.
Fallback logic ensures that a lack of modern protocol support does not automatically translate into a lost sale, maintaining the merchant's conversion rate across diverse cardholder bases.
Regulatory compliance and security
In jurisdictions governed by PSD2, authentication is a legal requirement for most remote transactions.
Falling back to 3DS1 allows merchants to remain compliant with Strong Customer Authentication (SCA) rules when the preferred 3DS2 path is unavailable, avoiding the risk of regulator-enforced transaction blocks or fines for non-compliance.
Protection against fraud liability
A primary advantage of 3D Secure is the shift of liability from the merchant to the issuer for fraudulent disputes.
Without a fallback mechanism, a merchant might be forced to process a transaction without any authentication, exposing themselves to financial loss if the transaction is later disputed as unauthorised.
Приложения
Cross-border trade
Merchants selling to customers in regions where 3DS2 adoption lags behind Europe or North America use fallback to maintain successful authentication rates.
Legacy issuer support
Retailers with a high volume of transactions from small regional banks or credit unions that still operate on legacy 3DS1 infrastructure.
High-risk transaction security
Businesses in high-risk sectors use fallback to ensure every possible authentication path is tried, maximising the chances of securing a liability shift.
Platform and marketplace stability
Marketplaces with diverse sub-merchants use fallback to ensure that varied card types and issuer responses do not disrupt the aggregate checkout experience.
В числа
Typical authentication success rates when fallback is enabled, as it captures transactions from issuers lacking modern protocol support.
The estimated decrease in technical declines observed by merchants when implementing automated versioning and fallback logic.
The standard processing overhead for the gateway to switch protocols, excluding the time taken for the cardholder to interact with the challenge.
Свързани термини
Talk to our team about a live rollout on your acquiring stack.
What you get with 3DS връщане към по-стара версия
- Автоматично откриване на 3DS2 неуспехи или неподдържани среди
- Безпроблемно пренасочване към 3DS1 за непрекъснато удостоверяване
- Поддържа съответствие с изискванията на SCA при различни сценарии
- Намалява техническите откази, свързани с несъвместимост на версията на 3DS
- Осигурява широка съвместимост с различни системи на издатели и придобиващи страни
- Минимизира клиентското недоволство, като предотвратява неуспешни плащания
- Analyses Directory Server responses to determine the highest available protocol version.
- Reduces the volume of hard declines caused by issuer non-participation in 3DS2.
- Assists in global expansion by supporting older bank technology in emerging markets.
- Minimises cart abandonment by providing an alternative authentication route during system outages.
A short scoping call, then a written plan for your MIDs.
Questions about 3DS връщане към по-стара версия
Какво е 3DS връщане към по-стара версия?
3DS връщане към по-стара версия е механизъм, при който, ако една трансакция не може да бъде обработена с помощта на 3D Secure 2. 0, системата автоматично се връща към използване на 3D Secure 1.
0. Това гарантира, че трансакцията все още може да бъде удостоверена и завършена, предотвратявайки отказ.
Защо 3DS връщане към по-стара версия е важно?
3DS връщане към по-стара версия е от решаващо значение за поддържане на високи нива на оторизация, особено по време на преходния период към 3DS2.
То смекчава проблемите с издатели или клиентски устройства, които може да не поддържат напълно 3DS2, като гарантира, че трансакциите се обработват сигурно и съвместимо.
Влияе ли 3DS връщане към по-стара версия на сигурността?
Въпреки че 3DS1 предлага различно потребителско изживяване, то все още осигурява слой на сигурност и помага за спазване на регулаторните изисквания за силно удостоверяване на клиента (SCA). Механизмът за връщане към по-стара версия гарантира, че сигурен метод за удостоверяване винаги се прилага, когато е необходимо.
How does the system decide when to trigger a fallback?
The fallback is triggered based on the response from the Scheme Directory Server or the Issuer Access Control Server.
Common triggers include a 'Status N' (Not Enrolled) response for 3DS2, a technical error code indicating the server is down, or a timeout where the 3DS2 versioning request fails to receive a response within a set timeframe (often 2-5 seconds).
Can I disable 3DS fallback for specific regions or MCCs?
Yes, payment orchestration settings usually allow for granular control.
A merchant might choose to disable fallback for regions where 3DS1 is fully decommissioned or for specific Merchant Category Codes (MCCs) where the friction of a legacy redirect is deemed too high relative to the transaction value.
However, for most European merchants, keeping it enabled is standard practice to maximise authorisation success.
What happens if both 3DS2 and 3DS1 fail?
If both protocols fail, the transaction will typically be sent to the issuer as 'unauthenticated'.
Depending on the merchant's risk settings and the regional regulations (like SCA), the transaction may be declined by the gateway before reaching the acquirer, or it may be passed through to the issuer who will likely decline it with a 'soft decline' code, requesting authentication.
Are there additional scheme fees associated with 3DS fallback?
Scheme fees for 3D Secure are generally applied per authentication attempt. While there is usually no specific 'fallback fee', the merchant will remain responsible for the standard 3DS inquiry fees.
Some acquirers may have different pricing tiers for 3DS2 versus 3DS1, so it is advisable to check the interchange-plus or blended pricing schedule for any variations in processing costs.
Готови ли сте за скорост?
Разкажете ни за вашия бизнес. Ние ще ви свържем с правилните банки акцептанти и правилния маршрут, обикновено в рамките на една седмица.