3DS Leak Check: does your checkout tell card testers which cards are worth using?
Scanner that shows whether a checkout's 3DS flow reveals card status before authorization. Payfacs and fraud consultants pay.
Early · 3DS Oracle paper maps BIN leak
Written for: Solo builder
Next step
Read the paper's integration patterns, then build a passive recorder that captures 3DS calls on your own test checkout in the Stripe and Adyen sandboxes and diffs them across test cards. Share what you find in r/stripe and merchant-fraud forums to gauge interest before building further.
Why now
This is the first formal map of the leak, and small merchants pay fees and suffer reputation damage when card testers hit them. But the fix depends on each provider's integration. Running a scanner against live merchant flows is legally and ethically delicate. And sandbox test cards may not reproduce real routing. It is too early to sell. Keep watching for provider advisories or a public test method.
What became possible
The 3DS Oracle paper shows that browser-based EMV 3-D Secure flows must expose a step the client can see, and that in some deployments this step reveals routing and authentication status before authorization. Card testers can use it to sort stolen card numbers without paying for an authorization. The paper backs this with formal modelling, a documentation audit and a bounded live test.
Two ways in
- Passive integration check
A browser extension that records 3DS network calls on a merchant's own checkout and flags responses that differ by card type before authorization.
- Customer
- Payment facilitators and e-commerce agencies
- Model
- $99 audit per checkout
- Provider matrix
A public table of which 3DS server and gateway integration patterns expose the step, updated as providers patch.
- Customer
- Fraud consultants and merchant risk teams
- Model
- Free table, paid detailed reports
Competition
I found no product, open-source tool or big-company feature that audits whether a merchant's 3DS integration reveals card status before authorization. The only direct coverage is a recent arXiv preprint and vendor blog posts.
Full competition notes (5 competitors)
I found no product, open-source tool or big-company feature that audits whether a merchant's 3DS integration reveals card status before authorization. The only direct coverage is a recent arXiv preprint and vendor blog posts. The rest of the market is runtime defense such as Stripe Radar, cside and other bot and velocity tools, which block attacks in progress but do not tell a payment facilitator or agency whether a checkout's design is the leak. A newcomer could win with a tool that runs only on checkouts the user is authorized to test. It would compare 3DS server, gateway and SDK patterns across a portfolio of merchants and produce evidence that payment facilitators can show acquirers or the card networks when card-testing numbers rise. A private, regularly updated matrix of which integration patterns leak would fit that well. The risks are that the 3DS server vendors (GPayments, Cardinal, Netcetera and others) or gateways patch the lookup-stage exposure or add their own checks and make it a one-off finding. The paper's authors or a fraud blog could also publish a free matrix. And a fully public matrix, or a probing tool that works on any site, would mainly help attackers, which hurts trust and sales to risk teams.
- The 3DS Oracle: BIN Attack via the Network (arXiv preprint)
Recent academic preprint arguing that some 3DS integrations return a client-visible lookup result before authorization, revealing account existence and routing state. It is research, not a product, but it confirms the problem and is the most likely seed for a public provider matrix.
- GPayments blog: Where 3D Secure Helps Against Card Testing, and Where It Doesn't
A 3DS server vendor publishing guidance on card testing through authentication, including monitoring many distinct cards per device and authorisation paths that skip authentication. It shows providers are aware of the problem and could ship their own checks, but it offers no scanner.
- Stripe card testing guidance and Radar
Says card testers collect 3DS or issuer responses to validate cards. Stripe stops attacks in progress on its own stack but does not audit whether a given integration leaks card status.
- cside card testing prevention
Session and behavior detection that runs before authorization to block automated card testing. Adjacent runtime defense, not an integration leak audit.
- Network Inspector (Chrome extension)
Generic request inspector that could record checkout traffic but knows nothing about 3DS and does not compare responses across card types. It shows the extension approach is easy to build but has no payments-specific player.
Checked 2026-10-26
Risks
- Testing anything other than your own checkout can count as unauthorised probing
- Sandbox behaviour may not match production routing
- Providers may patch quietly, which ends demand
- Fraud buyers lean enterprise, outside this reader's sweet spot
Strong open space; tech readiness and buildability are the weak point (4).
tech 4 · pull 5 · space 8 · fit 5 · build 4
Exposed
Companies that could benefit or be threatened. News and context, not investment advice.
Momentum of its main topic
Sources
Status history
- 2026-10-26 Added to the watchlist