Category: 3-D Secure

Challenge Request

Also known as: CReq, encodedCReq, creq, 3DS Challenge Request message

Simply put

A Challenge Request (CReq) is a message used during an EMV 3-D Secure challenge, the step where an issuer asks a shopper to prove their identity (for example, by entering a one-time passcode or approving a prompt in a banking app). In a browser-based checkout, the CReq is formed on the merchant side and delivered to the card issuer's authentication system through the cardholder's browser. It is one part of a message pair, with the issuer replying using a Challenge Response (CRes).

Formal definition

In EMV 3-D Secure v2.x, the Challenge Request (CReq) is the message that initiates and carries data for an issuer-driven cardholder challenge, addressed to the issuer's Access Control Server (ACS). Its origin and transport depend on the device channel: in browser-based flows (device channel 02-BRW), the 3DS Server forms the CReq and it is posted to the ACS URL via an HTTP form post through the cardholder browser, with the browser acting as transport rather than as the originator; in app-based flows (01-APP), the 3DS SDK is involved in the challenge exchange. Implementations commonly expose the CReq as a Base64URL-encoded value (for example, encodedCReq/creq) that must be posted to the ACS URL (acsUrl) to render the challenge. The CReq is paired with the Challenge Response (CRes) returned by the ACS. Per EMVCo specification wording, browser-based challenge flows use a single CReq message per challenge; practitioners should confirm exact message structure, required data elements, and channel-specific behavior against the current published EMV 3-D Secure specification, as details differ across versions and channels. Note that Decoupled Authentication is a challenge method whose CReq/CRes handling may differ from the general challenge flow.

Why it matters

The Challenge Request is the message that carries an issuer-driven cardholder challenge into the flow of an online payment, making it the pivot point between a frictionless authentication attempt and one where the shopper must actively prove identity. When an issuer's risk assessment calls for a step-up, the CReq is what delivers the cardholder to the issuer's Access Control Server so a challenge (such as a one-time passcode or an in-app approval) can be presented. Understanding which component forms and posts the CReq matters directly to anyone building, testing, or troubleshooting a checkout, because a misrouted or malformed CReq means the challenge never renders and the transaction cannot complete authentication.

Who it's relevant to

Payment integration and checkout developers

Developers building browser-based checkout flows need to know that the 3DS Server forms the CReq and that their implementation must post the encoded value (encodedCReq/creq) to the ACS URL through the cardholder browser to render the challenge. Misunderstanding which component originates versus transports the message is a common source of failed challenge rendering.

QA and integration testers

Testers validating 3-D Secure challenge behavior should confirm the single-CReq-per-challenge structure for browser flows and verify that the CReq is correctly posted to the acsUrl and that the paired CRes is handled. App-based (01-APP) flows involve the 3DS SDK and behave differently, so test coverage should account for channel-specific handling.

3DS Server and gateway operators

Operators responsible for forming and delivering the CReq need to ensure correct message formatting and routing to the issuer's ACS. Because Decoupled Authentication may differ from the general challenge flow, operators should confirm handling for each challenge method against the current specification.

Fraud and authentication strategy teams

Teams deciding when to request a challenge (for example, via a mandate-challenge preference flag) should understand that the CReq is the mechanism that carries a step-up into the flow. Requesting a challenge is intended to strengthen cardholder authentication, but it introduces friction, and the decision to challenge is one input among many in a broader authentication and fraud strategy.

Inside CReq

Message role and direction

The Challenge Request (CReq) is a message in the EMV 3-D Secure challenge flow directed to the issuer's Access Control Server (ACS). It is used during the challenge phase, after a transaction has been routed to a challenge rather than being frictionlessly authenticated.

Originating component (browser vs. app flows)

In browser-based (02-BRW) flows, EMV 3-D Secure v2.x specifies that the 3DS Server forms the CReq and posts it to the ACS through the cardholder's browser, which acts as the transport rather than the message creator. In app-based flows, the 3DS SDK on the cardholder's device forms and sends the CReq. Confirm the exact component responsibilities against the current published EMVCo 3-D Secure specification.

Message identification and control fields

A CReq carries control and identification fields that associate the message with a specific transaction and challenge session so the ACS can correlate it to the corresponding authentication. In browser (02-BRW) flows there is a single CReq per challenge; where applicable, any required authentication data may be conveyed in that single message. Refer to the current specification for the authoritative field list, since element definitions can differ between versions.

Relationship to the Challenge Response (CRes)

The CReq is paired with the Challenge Response (CRes) returned by the ACS. Together they support the interactive challenge exchange within the EMV 3-D Secure protocol. The CReq is one part of a broader flow that also involves authentication request/response messaging; it does not by itself complete authentication.

Common questions

Answers to the questions practitioners most commonly ask about CReq.

Does the shopper's browser create and send the CReq during a challenge?

Not in browser-based (02-BRW) flows. In EMV 3-D Secure v2.x browser flows, the 3DS Server forms the CReq message, which is then posted through the browser to the issuer's Access Control Server (ACS). The browser acts as transport, not as the component that formats or signs the message. In app-based flows, the 3DS SDK on the device handles the CReq. Attributing creation of the CReq to the browser itself is a common but material misconception, because it affects which component developers, testers, and compliance teams must scrutinize for message formatting and integrity.

Are there multiple CReq messages exchanged during a browser challenge, one carrying the cardholder's response?

For browser-based (02-BRW) flows, EMV 3-D Secure v2.x specifies a single CReq message per challenge, formed by the 3DS Server and posted through the browser to the ACS. The idea of a first control-only CReq followed by subsequent CReq messages carrying the cardholder's response does not match the browser flow as specified. The cardholder's interaction during the challenge is handled between the browser and the ACS, and the challenge concludes with the corresponding response messaging defined by the specification. Confirm the exact message sequence and data elements against the current published EMVCo specification, as details differ between app-based and browser-based flows and between versions.

Which component must format and sign the CReq, and why does that matter for implementation?

In browser-based flows the 3DS Server is responsible for forming the CReq; in app-based flows the 3DS SDK performs this role. This distinction matters because it determines where developers implement message construction, where testing and validation efforts should focus, and how components are treated when assessing scope. Misassigning this responsibility to the browser can lead to incorrect design and gaps in test coverage. Verify component responsibilities against the current EMVCo 3-D Secure specification for the version you are implementing.

How does the CReq reach the ACS if the browser is only transport?

In browser-based flows the 3DS Server forms the CReq and it is posted through the browser to the issuer's ACS, so the browser serves as the transport channel rather than the originator. Implementers should design the posting mechanism accordingly and treat the browser as an intermediary that conveys, rather than constructs, the message. The precise posting mechanics and endpoints are defined in the EMVCo specification and should be confirmed against the current published version.

How does the CReq differ between browser-based and app-based flows?

The core difference is which component forms the message and how it is transmitted. In browser-based (02-BRW) flows the 3DS Server forms the CReq and it is posted through the browser to the ACS. In app-based flows the 3DS SDK on the device handles the CReq. The message structure, data elements, and sequencing can differ between these device channels. Because these details are channel-specific and version-specific, confirm requirements for each flow against the current EMVCo 3-D Secure specification rather than assuming they are interchangeable.

What should testers verify when validating CReq handling?

Testers should confirm that the correct component forms the CReq for the relevant flow, meaning the 3DS Server for browser-based flows and the 3DS SDK for app-based flows, and that the message is transmitted to the ACS as specified. Test coverage should reflect the correct message sequencing for the flow being validated, and any data elements required by the specification should be verified for the applicable version and channel. Because message formatting, sequencing, and required fields depend on the version and flow, validate against the current published EMVCo 3-D Secure specification rather than assumptions carried over from other flows or versions.

Common misconceptions

The cardholder's browser creates and sends the CReq in browser-based flows.

In EMV 3-D Secure v2.x browser-based (02-BRW) flows, the 3DS Server forms the CReq and posts it to the ACS through the browser. The browser serves as transport, not as the component that formats or originates the message. In app-based flows, the 3DS SDK forms and sends the CReq. Confirm attribution against the current EMVCo specification.

A browser challenge involves multiple, sequential CReq messages that each carry the cardholder's response.

In browser-based (02-BRW) flows the specification defines a single CReq per challenge. There are not multiple 'subsequent' CReq messages in that flow. Where applicable, the single CReq may carry required authentication data. Verify message-count behavior against the current published specification, as details may differ by version and by channel (browser versus app).

A successful CReq/CRes exchange guarantees the transaction is not fraudulent.

EMV 3-D Secure challenge messaging is intended to help authenticate the cardholder and may support liability considerations under card brand and network rules, but it addresses only part of the transaction risk picture. It does not by itself eliminate fraud, and any liability shift is governed by card brand and network rules that vary by region and change over time.

Best practices

Implement CReq handling according to the channel: in browser-based (02-BRW) flows have the 3DS Server form the CReq and post it through the browser, and in app-based flows have the 3DS SDK form and send it; do not assign message creation to the browser.

Design browser flows around a single CReq per challenge rather than expecting multiple sequential CReq messages, and validate this behavior against the current published EMVCo 3-D Secure specification.

Confirm required data elements, field definitions, and component responsibilities against the current version of the EMVCo specification, since these can differ between versions and channels.

Ensure the CReq is correctly correlated to its transaction and challenge session using the specified control and identification fields so the ACS can match it to the intended authentication.

Treat the CReq/CRes exchange as one part of a layered authentication and fraud strategy, and avoid relying on it alone to make fraud or liability determinations, since liability shift is governed by card brand and network rules that vary by region.

Validate CReq formatting, transport, and error handling through EMVCo-aligned test cases before production, and re-verify when adopting a new specification version.