Skip to main content
Commerce Security Authority
Category: 3-D Secure

Results Request

Also known as: RReq, Results Request Message
Simply put

In the EMV 3-D Secure protocol, the Results Request (RReq) is a message used to communicate the outcome of a cardholder authentication. It is sent by the component that performed the authentication back through the payment authentication network so the result can be recorded and relayed to the merchant's side.

Formal definition

The RReq is an EMV 3-D Secure protocol message, originated by the Access Control Server (ACS), that communicates the results of an authentication attempt. The ACS sends the RReq to the Directory Server (DS), which relays it toward the 3DS Server; the 3DS Server acknowledges receipt by returning a Results Response (RRes) message. The RReq conveys the authentication outcome via the Transaction Status field—for example, in a decoupled authentication scenario the ACS may indicate a Decoupled Authentication Fallback using Transaction Status = 'D'. This message is specific to EMV 3-D Secure and should not be confused with the unrelated networking Route Request (RREQ) packet used in ad hoc routing protocols. Exact field definitions and behaviors vary by protocol version and should be confirmed against the current published EMVCo specification.

Why it matters

The Results Request (RReq) is the message that closes the loop on a cardholder authentication in EMV 3-D Secure. Without a reliable mechanism to communicate the authentication outcome back through the network, the merchant's side would have no authoritative record of whether the cardholder was successfully authenticated, challenged, or handled through an alternate flow. The RReq is what carries that outcome—expressed through the Transaction Status field—so it can be recorded and relayed toward the 3DS Server and, ultimately, the merchant.

Because the RReq conveys the definitive result of an authentication attempt, its correct handling matters for both fraud reduction and dispute processes. In scenarios such as decoupled authentication, where the cardholder is not authenticated in real time within the original challenge flow, the ACS uses the RReq to signal the appropriate state—for example, a Decoupled Authentication Fallback indicated with Transaction Status = 'D'. Misinterpreting or failing to process these results can lead to incorrect authentication decisions downstream. It is worth noting that 3-D Secure addresses authentication of the cardholder and does not, on its own, eliminate fraud; liability outcomes and network handling of authentication results are governed by card brand and network rules, which vary by region and change over time.

The RReq should not be confused with the unrelated Route Request (RREQ) packet used in ad hoc networking routing protocols; despite the similar abbreviation, these are entirely different concepts. Because exact field definitions and message behaviors differ across protocol versions, teams implementing or troubleshooting 3-D Secure flows should confirm current behavior against the published EMVCo specification rather than relying on a fixed assumption.

Who it's relevant to

3DS Server operators and integrators
Teams operating or integrating a 3DS Server need to correctly receive the relayed RReq, extract the Transaction Status, and return the corresponding Results Response (RRes). Proper handling ensures the authentication outcome is accurately recorded and made available to the merchant's side of the flow.
Access Control Server (ACS) providers
As the originator of the RReq, ACS providers (typically operating on behalf of issuers) are responsible for constructing the message and setting the Transaction Status to reflect the authentication outcome—including alternate states such as a Decoupled Authentication Fallback signaled with Transaction Status = 'D'. Accurate outcome reporting depends on correct RReq generation.
Directory Server and network operators
Directory Servers relay the RReq from the ACS toward the 3DS Server and facilitate the corresponding acknowledgment exchange. Understanding that the DS is a relay—not the party that produces the RRes acknowledgment—is important for correctly modeling message flow and troubleshooting where a result may have been lost or mishandled.
Payment engineers and QA teams
Engineers building or testing 3-D Secure integrations must interpret RReq fields and Transaction Status values correctly, and should confirm behavior against the current EMVCo specification, since field definitions vary by protocol version. They should also avoid confusing the 3DS RReq with the unrelated Route Request (RREQ) used in networking routing protocols.

Inside RReq

Message Purpose
The Results Request (RReq) is a message within EMV 3-D Secure used to convey the outcome of a challenge-based authentication back through the authentication ecosystem. It communicates the final transaction results after a challenge flow has completed.
Originating Component (ACS)
In the challenge flow, the Access Control Server (ACS) generates and sends the RReq to convey authentication results. Readers should confirm exact message-flow roles against the current published EMV 3-D Secure specification, as details may vary by version.
Message Routing via Directory Server
The Directory Server (DS) relays the RReq between components rather than acting as the terminating responder. The DS routes the message but does not itself originate the final acknowledgment to the ACS.
Acknowledging Responder (3DS Server)
Per EMV 3-D Secure specifications, the 3DS Server returns the Results Response (RRes) to acknowledge receipt of the RReq. The Directory Server relays the RRes back toward the ACS; it does not generate the acknowledgment itself.
Transaction Outcome Data
The RReq carries the results of the authentication attempt following a challenge, allowing the outcome to be conveyed to relevant parties. Exact data elements and field definitions should be confirmed against the current EMV 3-D Secure specification version, as field naming and content differ across versions.
Scope Boundary
The RReq is a construct defined by the EMV 3-D Secure (PCI 3DS-related but distinct) messaging framework and is specific to the challenge flow. It is separate from PCI DSS requirements and from authorization messaging handled by acquirers and networks.

Common questions

Answers to the questions practitioners most commonly ask about RReq.

Does the Directory Server generate and return the Results Response (RRes) to a Results Request (RReq)?
No. In the EMV 3-D Secure message flow, the 3DS Server returns the Results Response (RRes) to acknowledge receipt of the Results Request (RReq). The Directory Server relays the RReq and the corresponding RRes between the Access Control Server and the 3DS Server rather than originating the RRes itself. Confirm exact message roles and field definitions against the current EMVCo 3-D Secure specification, as message details can vary by version.
Is the RReq the message that carries the challenge to the cardholder?
No. The RReq conveys the results of authentication after processing, not the interactive challenge itself. The challenge interaction is handled through separate challenge-flow messages, and the RReq is used to transmit the final authentication outcome. Refer to the current EMVCo 3-D Secure specification for the precise sequence and the distinction between challenge messages and results messages.
Which component sends the RReq, and which one acknowledges it?
The Access Control Server sends the RReq, which is relayed through the Directory Server, and the 3DS Server returns the Results Response (RRes) to acknowledge it. Treat the Directory Server as a relay for these messages rather than the acknowledging endpoint, and verify component responsibilities against the current EMVCo 3-D Secure specification.
When in the transaction flow should the RReq be expected?
The RReq is associated with conveying the authentication results and is exchanged after the relevant authentication processing has occurred. Because message timing and applicability can differ across flow types and specification versions, confirm the expected sequencing for your specific flow against the current EMVCo 3-D Secure specification rather than assuming a fixed position.
What should an implementation do if the expected RRes acknowledgment is not received after sending an RReq?
Implementations should define handling for missing or delayed acknowledgments, including timeout and retry behavior, consistent with the current EMVCo 3-D Secure specification and any applicable Directory Server or card brand requirements. Because acknowledgment handling and error conditions are governed by the specification and network rules, confirm the required behavior against the current published documents rather than relying on assumptions.
How should RReq message fields be validated during integration testing?
Validate that message structure, required fields, and identifiers align with the field definitions in the current EMVCo 3-D Secure specification, and confirm that the 3DS Server correctly returns the RRes in response. Because field requirements can change between specification versions, base test cases on the current published specification and any Directory Server integration guidance rather than a fixed field list.

Common misconceptions

The Directory Server is the component that responds to the RReq with the Results Response (RRes).
EMV 3-D Secure specifications indicate that the 3DS Server returns the RRes to acknowledge the RReq. The Directory Server only relays the messages between components and does not act as the terminating responder.
The RReq is part of the authorization message flow between the merchant, acquirer, and card network.
The RReq is a message within the EMV 3-D Secure authentication protocol, specific to the challenge flow, and is distinct from authorization messaging. Authentication and authorization are separate steps addressing different points in a transaction.
A successful RReq/RRes exchange means fraud has been eliminated for that transaction.
3-D Secure authentication is intended to help reduce certain card-not-present fraud risks, but no single control eliminates fraud. Liability shift and related outcomes are governed by card brand and network rules, which vary by region and change over time.

Best practices

Confirm the exact roles of the ACS, Directory Server, and 3DS Server in the RReq/RRes exchange against the current published EMV 3-D Secure specification version rather than relying on assumed or legacy behavior.
Implement message handling so that the 3DS Server is treated as the component returning the Results Response (RRes), and the Directory Server as a relay, matching the specification's defined message flow.
Validate field definitions and data elements of the RReq against the specific EMV 3-D Secure version in use, since naming and content can differ between versions.
Keep 3-D Secure authentication messaging logically separate from authorization flows in your architecture and documentation to avoid conflating the two distinct transaction stages.
Do not rely on 3-D Secure results alone as a complete fraud control; combine them with other layered detection measures and account for false-positive and false-negative trade-offs.
Track card brand and network rule changes affecting liability shift and challenge-flow behavior by region, and update integration logic and expectations accordingly.