3-D Secure lookup results can expose account signals

In plain words

The research

What the evidence shows

• The question before authorization

  The paper studies whether a caller can learn account-related information from the first result of 3-D Secure (3DS), before financial authorization. That result may reflect how an authentication request is handled, but a challenge request does not mean the challenge was completed, and a result does not establish that a card can be used for payment.

  The authors combine protocol and integration analysis with bounded live testing and a separate review of public materials.

• Testing the visible result

  To examine what a caller could see, the researchers used a standalone HTTP client with valid authorization for their own merchant integration. It submitted synthetic browser and device information and received lookup results without running browser software.

  The client stopped before any challenge continuation or payment authorization. The measured evidence was the integration's first client-visible result, not raw messages exchanged internally by payment-network or issuer systems.

• A pattern with an exception

  The researchers compared a known-issued card they controlled with three adjacent, same-range card numbers that passed a basic format check. In six of seven tested card-range cohorts, the anchor's first-result class differed from all three comparison inputs.

  In the remaining cohort, all four inputs received a challenge-required result. The cohort, rather than each repeated session, was the unit of comparison; the result shows separation in some tested cases, not a validated classifier.

• Interpreting clues carefully

  The study also interprets returned transaction identifiers using a protocol rule: when the Directory Server creates a response on an issuer system's behalf, their identifiers should match. Matching or distinct identifiers can therefore be consistent with different processing tiers, if fields are mapped correctly and the specification is followed.

  They do not reveal internal processing directly or prove that an account exists. A separate routing check found previously blocked inputs received issuer-level responses through distributed residential proxies, within one integration and a modest proxy pool.

• What the evidence supports

  A separate review of public materials found examples of paid services and software that use 3DS results to screen candidate credentials. The authors interpret this evidence alongside the live observations as a reason to limit exposed response details and handle result branches consistently.

  Because the live test covered one main integration and did not verify candidate issuance or observe internal network processing, the evidence does not establish a universal account-validity test or how prevalent the signal is.