Does fallback trigger a second 3-D Secure authentication?
Not necessarily. When the payment moves to another provider in the same session, the authentication result can often be reused if the second provider supports it, so the shopper is not challenged twice. Where it cannot be reused, the fallback rule should weigh the cost of a second challenge against the chance of approval.
In detail
Not necessarily. When the payment moves to another provider in the same session, the authentication result can often be reused if the second provider supports it, so the shopper is not challenged twice. Where it cannot be reused, the fallback rule should weigh the cost of a second challenge against the chance of approval.
It depends on the providers
When a payment is authenticated with 3-D Secure and then declined by the first provider for a technical reason, the fallback attempt on a second provider can often reuse the authentication result: the same cryptogram, transaction ID and ECI value, passed in the new authorization. That works when the second provider accepts externally performed authentication, which most modern acquirers do.
When it cannot be reused
- The second provider requires authentication to go through its own 3-D Secure server.
- The authentication has expired or was tied to the first provider's merchant ID.
- The scheme rules for the card type do not allow reuse.
What the fallback rule should do
Weigh the cost of a second challenge, which risks abandonment, against the probability of approval on the second provider. For small amounts, a second challenge may lose more than it recovers; for large amounts, it is worth it. The platform should know, per provider, whether authentication reuse is supported, and the rule should be set per merchant and amount range. Reporting on fallback outcomes with and without a second challenge shows where the rule is right.