## TL;DR
The agent tries to drive a real bank's 3DS challenge page and breaks on iframes, device fingerprinting, or bot detection. Stop doing that. Test your own checkout's 3DS flow with the card network's sandbox and test cards, which simulate every challenge outcome deterministically. Automating real bank authentication pages is fragile, violates bank terms, and proves nothing about your integration.

```text
fraud agent browser automation failed on bank 3ds challenge page
```

## Use this when
- Browser automation fails inside a 3DS challenge during integration testing.
- Tests target your own checkout flow and need deterministic challenge outcomes.
- Challenge iframes load late or device data collection breaks the script.

## Not for this skill when
- You need to defeat or bypass a bank's authentication. Do not. That is never the fix.
- A real customer is stuck in a challenge. That is support, not automation.

## Steps
1. Confirm what the agent touches: if it is a real bank page, stop the run. Verify: the test targets your own checkout URL or the network sandbox, never a bank domain.
2. Switch to the card network's 3DS test harness with test card numbers covering each outcome: frictionless, challenge, failed, and abandoned. Verify: every outcome is reproducible on demand.
3. Drive only your checkout: trigger the challenge, handle the sandbox challenge iframe, complete it, and assert your order state updates. Verify: the full flow passes without touching a real bank.
4. Harden the script against known traps in your own pages: late-loading iframes, device data collection, and timeouts. Verify: explicit waits replace fixed sleeps.
5. Run the suite in CI on every checkout deploy. Verify: a 3DS regression fails the build before it reaches customers.

## Variant phrasings
### 3ds challenge page automation fails
Common phrasing.
### playwright 3ds test fails
Tool-focused search.
### selenium bank challenge page error
Tool-focused phrasing.

Compatibility: Playwright and Selenium against the Visa, Mastercard, and Amex 3DS sandboxes; the same principle holds for any issuer simulation.

## Why it happens
Real bank challenge pages are hardened against automation on purpose: device fingerprinting, behavioral checks, and bot detection. They are designed to defeat exactly what the agent is attempting, which is why the sandbox exists.

## Edge cases / pitfalls
- Sandbox behavior can drift from production; run a small set of real low-value transactions with employee cards as a smoke test, with consent.
- Never store real cardholder credentials or one-time codes in test fixtures.
- If a vendor asks you to automate their bank login for testing, decline. That is credential handling you do not want.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bf82P9gGUV3HrxDlknpV1g
