3‑D Secure authentication

General information

3‑D Secure (Three-Domain Secure) customer authentication is aimed at preventing fraud in processing of online card payments. This authentication procedure can be carried out in a variety of ways: the customer may be required to provide a one-time PIN (OTP) code, the customer's identity may be verified via facial recognition, the customer's fingerprint may be verified on their device, or the customer's involvement may be bypassed altogether based on the payment, device, and customer data. The choice of the authentication mechanism is decided on a case-by-case basis by the issuer.

3‑D Secure involves the interaction of three domains:

• Acquirer domain: in the context of the Ecommpay payment platform interoperability, it includes the merchant's web service, the payment platform, and its 3DS Server.
• Interoperability domain: it includes the Directory Servers (DS) of global card networks.
• Issuer domain: it includes the issuer's Access Control Servers (ACS) and the authentication page (ACS page).

The domains exchange messages that are required to authenticate the customer. These messages include the authentication request (Authentication Request Message, AReq) and the corresponding response (Authentication Response Message, ARes) as well as the customer authentication request (Challenge Request, CReq) and the response containing the authentication result information (Challenge Response, CRes).

Note that the information about the possibility of cardholder authentication is stored on the Access Control Server, and this information can be obtained only after a request to process a card payment has been sent. Moreover, the web service and the payment platform do not have control over customer actions on the authentication page; they can only receive the authentication result.

3‑D Secure authentication flows

3‑D Secure supports the following authentication flows:

• Challenge flow—authentication that requires the customer to perform certain actions in order to confirm their identity. Customers can be authenticated with the use of one-time code or biometric data if this capability is supported by the issuer, for example.
• Frictionless flow—authentication that does not involve interaction with the customer. Customers are authenticated with the use of data that the issuer already has.

The merchant cannot select the authentication flow. While the merchant can indicate which flow selection is preferable, the final decision is made by the issuer. In addition to specifying the preferred flow, the merchant can pass a range of optional parameters in the payment request which increases the possibility of the frictionless flow selection and thereby helps increase acceptance rates and enhances customer experience. Information about these and other parameters can be found below.

Overview

Similar to user scenarios, the 3‑D Secure workflows on the side on the web service and other parties can vary. In case of the web service, the authentication process is determined by the external decisions concerning the need for collecting additional data about the customer's device and the authentication flow. Each of such decisions can lead to the necessity to perform a specific procedure in addition to the basic steps of processing a payment.

The merchant cannot select any of these authentication scenarios on their own. However, they can influence the decisions made by other participants by passing recommended parameters and specifying which authentication flow (frictionless or challenge) is preferred for specific payments.

General workflow

The following is a general workflow of processing a payment with the 3‑D Secure authentication.

Information about the format of callbacks and requests used in this workflow can be found below. General information about using the Gate API is provided in Interaction concepts. Note that this workflow can also include other procedures and steps that do not have anything to do with the process of authentication and that are described in corresponding articles of this documentation.

Collecting the customer's device characteristics

When the issuer requires collection of additional data about the customer's device characteristics, the payment platform sends an appropriate callback to the web service. If you receive this callback:

1. Check the integrity of data in the callback by verifying the signature.
2. Confirm accepting and validating the callback by sending a 200 OK synchronous response to the platform.
3. Open the iframe element to collect the customer's device characteristics using the data received in the callback (details).
4. Accept the message acknowledging receipt of data from the issuer's Access Control Server.
5. Send the authentication initiation request to the payment platform.

Redirecting the customer to the ACS page

If the issuer selects the challenge flow with redirection of the customer to the ACS page, the payment platform sends an appropriate callback to the web service. If you receive this callback:

1. Check the integrity of data in the callback by verifying the signature.
2. Confirm accepting and validating the callback by sending a 200 OK synchronous response to the platform.
3. Redirect the customer to the authentication page using the data received in the callback (details) within 30 seconds after the callback was received.
4. Accept the authentication result from the issuer.
5. Send a payment completion request with the authentication result within 30 minutes after the callback that indicates the need for redirection was received.
6. If the cascading payments option is enabled (details) and your web service receives an additional callback containing the cascading_with_redirect parameter (set to true), your web service is required to do the following:
   1. Repeat step 1-2 of this procedure, accepting and validating the callback.
   2. Display an authentication attempt error message to the customer.
   3. Receive the customer's consent for retrying authentication.
   4. Repeat steps 3-5 of this procedure.

To improve user experience and increase payment acceptance rates, strive to minimise the number of actions the customers need to perform in the process of authentication. To do so, you are recommended to pass certain optional parameters in requests for processing payments that will require 3‑D Secure. These parameters help decrease the likelihood that procedures to collect additional data about the customer's device and to redirect the customer to the ACS page will be needed. Alongside the information about the customer and the payment listed below, you should include the following information about the customer's device and browser:

• Information about the device collected on the client side of the web service:
  • accept_header—value of the HTTP Accept request header
  • accept_language_header—value of the Accept-Language HTTP request header that specifies the preferred localisation language
  • browser—value of the HTTP User-Agent request header
  • ip_address—IP address of the customer during the payment session
• Information about the device retrieved from the request sent from the browser to the web service:
  • color_depth—colour depth of the customer's device, bits per pixel
  • java_enabled—indicator that specifies whether the customer's browser supports Java
  • js_enabled—indicator that specifies whether the customer's browser supports JavaScript
  • language—code of the customer's browser language
  • screen_res—screen resolution of the customer's device, in pixels, with an x character as a delimiter (for example, 1920x1080)
  • timezone_name—name of the time zone the customer's browser is set to (for example, Australia/Adelaide)
  • timezone_offset—difference between a date as evaluated in the UTC time zone and the same date as evaluated in the browser time zone, specified in minutes, (for example, 570)

    "customer": {
    "ip_address": "188.113.253.90",
    "browser": "Mozilla/5.0 (Linux; Android 14; SM-A155F Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/138.0.7204.67 Mobile Safari/537.36",
    "screen_res": "1920x1080",
    "language": "en_US",
    "accept_header": "*/*",
    "accept_language_header": "en-GB,en;q=0.8,fr;q=0.3",
    "color_depth": 24,
    "java_enabled": false,
    "js_enabled": true,
    "timezone_offset": "570"
  }

To collect these data, configure your web service to perform the following steps.

1. Determine the customer's device characteristics on the client side of the web service.

   function collectClientData() {
       return {
           // screen resolution of the device 
           screen_res: `${screen.width}x${screen.height}`,
            
           // code of the browser language
           language: navigator.language,
            
           // colour depth of the browser
           color_depth: screen.colorDepth,
            
           // indicates whether Java is enabled in the browser
           java_enabled: navigator.javaEnabled(),
            
           // indicates whether JavaScript is enabled in the browser
           js_enabled: true,
            
           // differnce between the browser time zone and the UTC
           timezone_offset: new Date().getTimezoneOffset().toString(),
       };
   }

2. Send the collected data from the client side to the server side of the web service.

   async function sendClientDataToServer(endpoint = '/api/collect-client-data') {
       try {
           const clientData = collectClientData();
             
           const response = await fetch(endpoint, {
               method: 'POST',
               headers: {
                   'Content-Type': 'application/json',
                   'Accept': '*/*'
               },
               body: JSON.stringify(clientData)
           });
             
           const result = await response.json();
           return result;
       } catch (error) {
           console.error('Failed to send data:', error);
           throw error;
       }
   }

3. On the server side of the web service, add the data collected from the request sent from the customer's browser to the web service as well as other parameters necessary for sending the request, generate the signature, and send the request to the Ecommpay URL.

   interface CustomerData
   {
       public function getIpAddress(): ?string;
    
       public function getAcceptHeader(): ?string;
    
       public function getAcceptLanguageHeader(): ?string;
    
       public function getScreenRes(): ?string;
    
       public function getBrowser(): ?string;
    
       public function getLanguage(): ?string;
    
       public function getColorDepth(): ?int;
    
       public function getJavaEnabled(): ?bool;
    
       public function getJsEnabled(): ?bool;
    
       public function getTimezoneOffset(): ?string;
   }
    
   interface CardData
   {
       public function getPan();
    
       public function getYear();
    
       public function getMonth();
    
       public function getCardHolder();
    
       public function getCvv();
   }
    
   interface PaymentData
   {
       public function getPaymentId(): string;
    
       public function getAmount(): int;
    
       public function getCurrency(): string;
    
       public function getCardData(): CardData;
    
       public function getCustomerData(): CustomerData;
   }
    
   interface HttpClient
   {
       public function sendRequest(array $request): bool;
   }
    
   interface Signer
   {
       public function sign(array $params): string;
   }
    
   final class PaymentController
   {
       public function __construct(
           private Signer $signer,
           private HttpClient $httpClient,
           private int $projectId,
       ) {}
    
       public function processPayment(PaymentData $paymentData): void
       {
           $paymentRequest = [
               'general' => [
                   'project_id' => $this->projectId,
                   'payment_id' => $paymentData->getPaymentId(),
               ],
               'customer' => $this->prepareCustomerData($paymentData->getCustomerData()),
               'payment' => [
                   'amount' => $paymentData->getAmount(),
                   'currency' => $paymentData->getCurrency(),
               ],
               'card' => [
                   'pan' => $paymentData->getCardData()->getPan(),
                   'year' => $paymentData->getCardData()->getYear(),
                   'month' => $paymentData->getCardData()->getMonth(),
                   'card_holder' => $paymentData->getCardData()->getCardHolder(),
                   'cvv' => $paymentData->getCardData()->getCvv(),
               ],
           ];
    
           $paymentRequest['general']['signature'] = $this->signer->sign($paymentRequest);
    
           $this->httpClient->sendRequest($paymentRequest);
       }
    
       private function prepareCustomerData(CustomerData $customerData): array
       {
           return array_filter([
               'ip_address' => $customerData->getIpAddress(),
               'browser' => $customerData->getBrowser(),
               'screen_res' => $customerData->getScreenRes(),
               'language' => $customerData->getLanguage(),
               'accept_header' => $customerData->getAcceptHeader(),
               'accept_language_header' => $customerData->getAcceptLanguageHeader(),
               'color_depth' => $customerData->getColorDepth(),
               'java_enabled' => $customerData->getJavaEnabled(),
               'js_enabled' => $customerData->getJsEnabled(),
               'timezone_offset' => $customerData->getTimezoneOffset(),
           ]);
       }
   }

   package main
    
   import "encoding/json"
    
   // CustomerData interface
   type CustomerData interface {
       GetIpAddress() *string
       GetAcceptHeader() *string
       GetAcceptLanguageHeader() *string
       GetScreenRes() *string
       GetBrowser() *string
       GetLanguage() *string
       GetColorDepth() *int
       GetJavaEnabled() *bool
       GetJsEnabled() *bool
       GetTimezoneOffset() *string
   }
    
   // CardData interface
   type CardData interface {
       GetPan() interface{}
       GetYear() interface{}
       GetMonth() interface{}
       GetCardHolder() interface{}
       GetCvv() interface{}
   }
    
   // PaymentData interface
   type PaymentData interface {
       GetPaymentId() string
       GetAmount() int
       GetCurrency() string
       GetCardData() CardData
       GetCustomerData() CustomerData
   }
    
   // HttpClient interface
   type HttpClient interface {
       SendRequest(request map[string]interface{}) bool
   }
    
   // Signer interface
   type Signer interface {
       Sign(params map[string]interface{}) string
   }
    
   // PaymentController struct
   type PaymentController struct {
       signer     Signer
       httpClient HttpClient
       projectId  int
   }
    
   // NewPaymentController constructor
   func NewPaymentController(signer Signer, httpClient HttpClient, projectId int) *PaymentController {
       return &PaymentController{
           signer:     signer,
           httpClient: httpClient,
           projectId:  projectId,
       }
   }
    
   // ProcessPayment processes the payment
   func (pc *PaymentController) ProcessPayment(paymentData PaymentData) {
       cardData := paymentData.GetCardData()
    
       paymentRequest := map[string]interface{}{
           "general": map[string]interface{}{
               "project_id": pc.projectId,
               "payment_id": paymentData.GetPaymentId(),
           },
           "customer": pc.prepareCustomerData(paymentData.GetCustomerData()),
           "payment": map[string]interface{}{
               "amount":   paymentData.GetAmount(),
               "currency": paymentData.GetCurrency(),
           },
           "card": map[string]interface{}{
               "pan":         cardData.GetPan(),
               "year":        cardData.GetYear(),
               "month":       cardData.GetMonth(),
               "card_holder": cardData.GetCardHolder(),
               "cvv":         cardData.GetCvv(),
           },
       }
    
       // Add signature
       general := paymentRequest["general"].(map[string]interface{})
       general["signature"] = pc.signer.Sign(paymentRequest)
    
       // Send request
       pc.httpClient.SendRequest(paymentRequest)
   }
    
   // prepareCustomerData filters and prepares customer data
   func (pc *PaymentController) prepareCustomerData(customerData CustomerData) map[string]interface{} {
       result := make(map[string]interface{})
    
       if v := customerData.GetIpAddress(); v != nil {
           result["ip_address"] = *v
       }
       if v := customerData.GetBrowser(); v != nil {
           result["browser"] = *v
       }
       if v := customerData.GetScreenRes(); v != nil {
           result["screen_res"] = *v
       }
       if v := customerData.GetLanguage(); v != nil {
           result["language"] = *v
       }
       if v := customerData.GetAcceptHeader(); v != nil {
           result["accept_header"] = *v
       }
       if v := customerData.GetAcceptLanguageHeader(); v != nil {
           result["accept_language_header"] = *v
       }
       if v := customerData.GetColorDepth(); v != nil {
           result["color_depth"] = *v
       }
       if v := customerData.GetJavaEnabled(); v != nil {
           result["java_enabled"] = *v
       }
       if v := customerData.GetJsEnabled(); v != nil {
           result["js_enabled"] = *v
       }
       if v := customerData.GetTimezoneOffset(); v != nil {
           result["timezone_offset"] = *v
       }
    
       return result
   }

Overview

The format of requests for processing payments that will require 3‑D Secure must correspond to the format described in Interaction concepts. At the same time, each request may require a different parameter set as follows:

• Without exception, you must include the parameters that are required for the payment type to be initiated (more information can be found in the articles about payment types) and the parameters listed below as required for performing 3‑D Secure.
• If the frictionless flow is preferred, you are recommended to specify as many optional parameters listed below as possible for performing 3‑D Secure.
• Additionally, you can use any other parameters out of the supported parameter set for the payment type to be initiated.

Required parameters

In requests for processing payments that will be subject to 3‑D Secure, pass the required parameters for the specific payment type and additionally include the following required objects and parameters.

{
  "general": {
      "project_id": 42,
      "payment_id": "456789",
      "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...=="
  },
    "customer": {   // information about the customer
      "ip_address": "248.121.176.220",   // IP address of the customer
      "id": "customer_12",
      "screen_res": "1920x1080",   // screen resolution of the customer's device
      "phone": "44991234567",   // customer's phone number
      "email": "john_smith@email.com"   // customer's email
  },
    "payment": {
      "amount": 400000,
      "currency": "USD"
  },
    "return_url": {
      "success": "https://example.com/success",
      "decline": "https://example.com/decline"
  },
    "card": {
      "pan": "4314220000000056",
      "year": 2025,
      "month": 8,
      "card_holder": "JOHN SMITH",   // name of the cardholder
      "cvv": "123"
  },
  "acs_return_url": {   // information about the web service URLs
    "return_url": "https://3DS_result_url",   // URL to redirect the customer to after authentication
    "3ds_notification_url": "https://3DS_result_url"   // URL for accepting receipt acknowledgement
  }

Recommended parameters

In requests for processing payments that will be subject to 3‑D Secure, you are recommended to specify parameters listed below because it can increase the possibility of frictionless flow selection that bypasses interaction with the customer and does not require the procedure of collecting additional data about the customer's device. The web service can pass all or some of the parameters, depending on the availability of specific data. The bare minimum of the parameters that affect the issuer's decision when selecting the 3‑D Secure flow includes the billing address of the customer and the customer's device and browser characteristics.

Callback format when collecting additional data is needed

When the issuer requires collecting additional data about the customer's device, you need to accept an intermediate callback from the payment platform and use the data included in the iframe object of the threeds2 object to generate an iframe element on the page of the web service. Such callbacks are arranged in a standard format (details), while the iframe object contains the data to be used as follows: specify the value of the url parameter from the iframe data as the value of the action attribute and specify the values of other parameters inside the corresponding input tags of the iframe code.

{ 
  "threeds2":{ 
    "iframe":{ 
      "url":"https://example.com",
      "params":{
        "3DSMethodData":"eyAidGhyZWVNrkthelJSUFQwaWZYMCUzQ",
        "threeDSMethodData":"eyAidGhjNjMGQ4YWU4LTA2u0wyWmtObGRdwR"
      }
    }
  }
}

<iframe id="tdsMmethodTgtFrame" name="tdsMmethodTgtFrame" style="width: 1px; height: 1px; 
display: none;" src="javascript:false;" xmlns="http://example.com/xhtml"> <!--.--> </iframe>
<form id="tdsMmethodForm" name="tdsMmethodForm" action="https://example.com" method="post" 
target="tdsMmethodTgtFrame" xmlns="http://example.com/xhtml">
    <input type="hidden" name="3DSMethodData" value="eyAidGhyZWVNrkthelJSUFQwaWZYMCUzQ"
    />
    <input type="hidden" name="threeDSMethodData" value="eyAidGhjNjMGQ4YWU4LTA2u0wyWmtObGRdwR"
    />
</form>
<script type="text/javascript" xmlns="http://example.com/xhtml">
    document.getElementById("tdsMmethodForm").submit();
</script>

Format of the message acknowledging receipt of additional data

Messages that acknowledge receipt of additional data about the customer's device are arranged in the format chosen by the issuer. The issuer's Access Control Server sends a message with an acknowledgement to the web service URL provided in the initial payment request (in the 3ds_notification_url parameter). If you have questions about working with these messages, refer to the Ecommpay technical support.

threeDSMethodData:eyJ0aHJlZURTU2VydmVyVHJhbnNJRCI6ImRiNmFjM2UwLWI5ZWQtNWQ3NS04MDAwLTAwMDAwMDAwMTA0MiJ9
threeDSServerTransID=3abd37b3-afa6-53cf-8000-000000006455

Format of the authentication initiation request

To initiate the authentication, if it is necessary after collecting the customer's device characteristics, send a HTTP POST request to the /v2/payment/card/3ds_check_iframe endpoint. The request must contain the following objects and parameters:

• general—the object containing the general identification information of the request:
  • project_id—the project identifier.
  • payment_id—the payment identifier.
  • signature—the request signature generated after all required parameters have been specified. For more information about signature generation, see Signature generation and verification.
• threeds_completion_indicator—the parameter that indicates whether the message acknowledging the receipt of data was received within 10 seconds after the iframe element was opened. If the acknowledgement was received within 10 seconds, pass true; if not, pass false.

Thus, a correct request for the 3‑D Secure authentication initiation contains a project identifier, a payment identifier, an indicator of timely receipt of the acknowledgement message, and a signature.

{ 
  "general":{ 
    "project_id":42,
    "payment_id":"456789",
    "signature":"v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...=="
  },
  "threeds_completion_indicator":true
}

Callback format when redirection is needed

To redirect the customer from your web service to the ACS URL, you need to accept an intermediate callback from the payment platform and use the data included in the redirect object of the threeds2 object. Such callbacks are arranged in a standard format (details), while the redirect object contains the data to be used as follows: specify the value of the url parameter as the value of the action attribute and specify the values of other parameters inside the corresponding input tags of the HTML code.

{ 
  "threeds2":{ 
    "redirect":{ 
      "url":"https://example.com/ACS",
      "params":{
        "creq":"ewogICAiYWNzVHJhbnNJCIDAtMDAwMDAwMDAwN2Q5Ip9",
        "threeDSSessionData":"240000549"
      }
    }
  }
}

<!DOCTYPE html SYSTEM "about:legacy-compat">
<html class="no-js" lang="en" xmlns="http://example.com/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <meta charset="utf-8" />
    <title>3D Secure Processing</title>
    <link href="https://example.com/mpi.css" rel="stylesheet" type="text/css" />
  </head>
  <body>
    <div id="main">
      <div id="content">
        <div id="order">
          <h2>3D Secure Processing</h2>
          <img src="https://example.com/preloader.gif" alt="Please wait.." /> <img src="https://
example.com/verifiedbyvisa.png" alt="Verified by VISA" />
          <div id="formdiv">
            <script type="text/javascript">
              function hideAndSubmitTimed(formid) { timer=setTimeout("hideAndSubmit('"+formid+"');",
100);} function hideAndSubmit(formid) { var formx=document.getElementById(formid); tif (formx!=null)
{ formx.style.visibility="hidden"; formx.submit(); } }
            </script>
            <div>
              <form id="webform0" name="red2ACSv2" method="POST" action="https://
example.com/ACS" accept_charset="UTF-8"> 
<input type="hidden" name="_charset_" value="UTF-8" /> 
<input type="hidden" name="creq" value="ewogICAiYWNzVHJhbnNJCIDAtMDAwMDAwMDAwN2Q5Ip9" /> 
<input type="hidden" name="threeDSSessionData" value="240000476" /> 
<input type="submit" name="submitBtn" value="Please click here to continue" /> 
              </form>
            </div>
          </div>
          <script type="text/javascript">
           thideAndSubmitTimed('webform0');
          </script>
          <noscript>
            <div align="center"> <b>Javascript is turned off or not supported!</b> <br/> </div>
          </noscript>
        </div>
      </div>
    </div>
  </body>
</html>

Format of the message with the authentication result

Messages with authentication results are arranged in the format chosen by the issuer. They should contain the cres parameter that then is passed to the platform from the web service in the payment completion requests.

cres=ewogICJhY3NUcmFuc0lEIiA6ICJkYTIyNjY0Mi1hYzJhLTQ0N2ItYWFiYS1lNWI2Nzc2MjdmZmMiLAogICJtZXNzYWdlVHlwZSIgOiAiQ1JlcyIsCiAgIm1lc3NhZ2VWZXJzaW9uIiA6ICIyLjEuMCIsCiAgInRocmVlRFNTZXJ2ZXJUcmFuc0lEIiA6ICI5ZjE3OWM0My02NjA2LTU3YWUtODAwMC0wMDAwMDAwMDA3ZGQiLAogICJ0cmFuc1N0YXR1cyIgOiAiWSIKfQ&threeDSSessionData=240000554

cres=ewogICAiYWNzUmVmZXJlbmNlTnVtYmVyIiA6ICJBQ1NFbXUyIiwKICAgImFjc1RyYW5zSUQiIDog%0D%0AIjAwMDAwMDAwLTAwMDUtNWE1YS04MDAwLTAxNmQzZTI2ZWU2YyIsCiAgICJtZXNzYWdlVHlwZSIg%0D%0AOiAiQ1JlcyIsCiAgICJtZXNzYWdlVmVyc2lvbiIgOiAiMi4xLjAiLAogICAidGhyZWVEU1NlcnZl%0D%0AclRyYW5zSUQiIDogIjhiMjM0Y2ZmLTkzNjAtNTc5Yy04MDAwLTAwMDAwMDAwMDlhNiIsCiAgICJ0%0D%0AcmFuc1N0YXR1cyIgOiAiTiIKfQ==&threeDSSessionData=240000622

Format of the payment completion request

To resume processing of the payment, once the challenge flow has been completed, send a request to the /v2/payment/card/3ds_result endpoint using the POST HTTP method. The request must contain the following objects and parameters:

• general—the object containing the general identification information of the request:
  • project_id—the project identifier.
  • payment_id—the payment identifier.
  • signature—the request signature generated after all required parameters have been specified. For more information about signature generation, see Signature generation and verification.
• cres—the parameter containing the customer's 3‑D Secure authentication result sent in the message from the Access Control Server.

Thus, a correct request for payment completion following the 3‑D Secure authentication contains project and payment identifiers, the signature, and the authentication result.

{
   "general": {
   "project_id": 42,
   "payment_id": "456789",
   "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...=="
   },
   "cres": "ewogICJhY3NUcmFuc0lEIiA6ICJkYTIyNjY0Mi1hYzJhLTQ0N2ItYWFiYS1lNWI2Nzc2MjdmZmMi
LAogICJtZXNzYWdlVHlwZSIgOiAiQ1JlcyIsCiAgIm1lc3NhZ2VWZXJzaW9uIiA6ICIyLjEuMCIsCiAgInRocmVlR
FNTZXJ2ZXJUcmFuc0lEIiA6ICI5ZjE3OWM0My02NjA2LTU3YWUtODAwMC0wMDAwMDAwMDA3ZGQiLAogICJ0cmFuc1
N0YXR1cyIgOiAiWSIKfQ"  // Authentication result data
}