Guide
Most 3DS failures are not authentication failures
The challenge usually succeeds. What fails is the page around it — the redirect, the remount, the cart that resets.
The customer is not abandoning the challenge
Watch a challenged payment and the pattern is rarely a refusal to authenticate. The customer taps the bank prompt, confirms in their banking app, and then lands on a page that has lost the cart, the coupon or the session entirely.
The authentication succeeded. The checkout died around it. Those are different failures with different fixes.
Remounting is the expensive part
A checkout that unmounts during a redirect has to rebuild its state on return. If the surrounding page treats the redirect as a full navigation, the cart rehydrates from scratch and the customer sees a summary they no longer trust.
Inline challenges solve this by keeping the checkout mounted while the issuer's step runs over the page. Nothing is torn down, so nothing has to be rebuilt.
The trace tells you where it stalled
Detect, authenticate, poll, probe and relay are recorded with their HTTP codes. A run that stalled at authenticate is a different failure from one that stalled at poll.
Reading the trace is cheaper than reproducing the checkout, and it names the request that stalled instead of describing the symptom.
Measure the right thing
Challenge pass rate is not the metric. Settled runs after a passed challenge is the metric, because that is where the money is lost despite a successful authentication.
Track challenges issued, challenges completed, and settled payments afterwards. The gap between the last two numbers is the redirect tax you are paying.
Apply it without writing a retry engine
The extension ships the scheduling described here. Install it against a test key and watch one declined card get its attempts.