Home / Wiki / C / Challenge Flow

Challenge Flow

Cards and IssuanceUpdated 15 Nov 2026

A challenge flow is the interactive path of a 3-D Secure 2 authentication, in which the card issuer decides it needs more proof that the shopper is the genuine cardholder and asks them to complete a check. Typical challenges are entering a one-time passcode sent by text message, approving the purchase in the bank's mobile app or confirming with a fingerprint or face scan. Only when the cardholder passes does the merchant receive an authentication result that it can use to request payment authorisation.

The challenge flow is the alternative to the frictionless flow, where the issuer approves the cardholder silently on the basis of data sent by the merchant. A third path, decoupled authentication, lets the cardholder authenticate later or on another device. In the European Economic Area and the UK, challenge flows are the usual way of meeting strong customer authentication rules for online card payments when no exemption applies.

01

When a challenge is triggered

The decision belongs to the card issuer, through its access control server. The issuer's risk-based authentication engine weighs the data received, such as device details, purchase amount, shipping address and the customer's history with the merchant. A challenge is more likely when:

  • Risk looks higher. The device is new, the location unusual, the amount large or the merchant category prone to fraud.
  • The law requires it. Strong authentication is needed and no strong customer authentication exemption applies, or the cumulative limits of the low-value exemption have been reached.
  • The merchant asks for it. 3-D Secure messages include a challenge indicator through which the merchant can state a preference, for example requesting a challenge when a card is first stored for future payments.
  • Data is missing. Poor-quality or incomplete data from the merchant leaves the issuer unable to assess the risk confidently.
02

How the challenge works

  1. The merchant's 3DS server sends an authentication request, and the issuer replies that a challenge is required.
  2. The issuer's challenge screen is shown to the cardholder: in a browser, as a window or embedded frame within checkout; in a mobile app, as native screens built with the 3DS software development kit.
  3. The cardholder completes the challenge, such as entering a one-time password, approving a push notification in the banking app or using biometric authentication.
  4. The issuer sends the result to the 3DS server through the card scheme's directory server, and the merchant receives an authentication value to include in its authorisation request.

Under European rules, the challenge must show the cardholder the amount and the payee, and the resulting authentication code must be tied to them, a requirement known as dynamic linking. Out-of-band methods, in which the cardholder approves in a separate banking app, are increasingly common because they are more secure and easier to use than text message codes.

03

Effect on conversion

Challenges add friction. Some shoppers abandon payments because they do not receive the code, cannot find their banking app, face slow or badly designed screens, or time out. Industry data has repeatedly shown that challenged payments complete less often than frictionless ones, with large differences between issuers. Merchants and their providers therefore try to keep challenges to those that are necessary, by sending complete and accurate data, applying for exemptions where allowed and designing checkout pages that display challenge windows properly on mobile devices.

04

Liability and outcomes

A successfully completed challenge produces a fully authenticated transaction, and under card scheme rules liability for most fraud-related chargebacks generally shifts from the merchant to the issuer. If the cardholder fails or abandons the challenge, the merchant should not proceed with the payment, and if the issuer cannot complete the authentication for technical reasons, the merchant must decide whether to authorise without it and accept the fraud risk. Issuers also learn from challenge results: a cardholder who regularly passes challenges with a given merchant and device is more likely to be approved frictionlessly next time.

05

Design and good practice

Card schemes and EMVCo publish user interface guidelines for challenge screens, covering branding, clarity, accessibility and the information shown. Good practice includes showing the merchant name and amount, using the bank's app rather than text messages where possible, allowing enough time to respond, and offering a clear way to cancel. Merchants should test how challenges appear in their apps and web checkout, since layout problems are a frequent and avoidable cause of failed payments.

Last updated 15 Nov 2026