Authentication by using 3‑D Secure 2

3‑D Secure 2 is a new version of the 3‑D Secure protocol which is intended to secure e-commerce card payments. The key advantages of 3‑D Secure 2, as compared to 3‑D Secure 1, include the following:

• Extended payment options thanks to support of authentication in mobile apps. (No browser is required.)
• Enhanced security thanks to no static passwords (for instance password sets issuer provides) and use of more secure authentication methods—for example by using biometric data—and support for extended customer details provided when performing authentication.
• More convenient payment procedure and increasing payment conversion rate thanks to new flow for authenticating customer by issuer with no customer interaction.

3‑D Secure 2 supports two authentication flows: frictionless flow and challenge flow. In the frictionless flow, the customer authentication is performed with no customer interaction. The challenge flow requires the customer to provide additional authentication information such as one-time code (as in 3‑D Secure 1) or biometric data.

The choice between frictionless flow or challenge flow is performed by the issuer based on available information about the customer including the customer information provided by the merchant. The information may include customer account details in merchant stored web service or delivery address. To increase probability of selecting the frictionless flow, it is recommended that merchant collects and submits additional related to customer parameters.

As 3‑D Secure 1, the 3‑D Secure 2 uses three domains:

• Acquirer domain In the context of the Rocketpay payment platform interoperability, it includes merchant web service, the payment platform, and its 3DS Server.
• Interoperability domain The infrastructure provided by the card scheme, for instance Directory Server (DS).
• Issuer domain This includes the issuer's Access Control Server (ACS) (and the authentication page deployed on ACS).

Note that the information about the possibility of customer authentication is stored on the 3DS Server, and therefore this information can only be obtained after sending a payment request. Also, the payment platform does not have control over customer actions on the authentication page, but only receives the authentication result.

For more information about interoperability of the domains, see 3‑D Secure 2 workflow in Payment Page.

This section provides the answers to the common questions regarding 3‑D Secure 2 and its support and usage options.

General protocol issues

• What is the difference between 3‑D Secure 2 and 3‑D Secure 1?
• Are there any changes in the end-user experience?
• What are the procedures for handling customer's biometric data?
• Can I find out in advance whether customer must be authenticated?
• Are there any payments that do not require the 3‑D Secure 2 authentication?
• Can I altogether avoid 3‑D Secure 2 authentication when performing payments that are exempt from 3‑D Secure 2?

Adopting and implementation

• What is required to implement 3‑D Secure 2?
• How does the implementation of 3‑D Secure 2 affect the Payment Page payments?
• Do you offer test cards to set up and debug the new workflow?

Usage options

• Can I use 3‑D Secure 2 for all payments with Visa, Mastercard, and Maestro cards?
• Do I need to support 3‑D Secure 1 if I use 3‑D Secure 2?
• Can merchant choose to use 3‑D Secure 1 instead of 3‑D Secure 2?
• Is there a tool I can use to find out the protocol that was used?
• Is it possible to process payments without authenticating by using 3‑D Secure (non-3DS)?

For more information regarding 3‑D Secure 2, refer to your account manager at Rocketpay.

What is the difference between 3‑D Secure 2 and 3‑D Secure 1?

User experience becomes flexible with optional customer redirection to the preload page hosted on the payment platform, the support of the two authentication flows—frictionless flow and challenge flow, and new customer authentication methods (for example using biometric data in a mobile app).

The communication between merchant web services and the Rocketpay payment platform was enhanced to include new parameters and new data structures in callbacks. To move to 3‑D Secure 2, merchants are required to register with Visa Secure and/or Mastercard Identity Check and place Visa Secure and/or Mastercard Identity Check logos on their payment pages.

It is not mandatory to support all these changes in your web service but it is required to place the logos on merchant payment pages.

Are there any changes in the end-user experience?

Unlike 3‑D Secure 1 in which the authentication procedure is always performed with a single redirect, in 3‑D Secure 2 the number of redirects may differ:

• If your web service uses the same scheme as 3‑D Secure 1 authentication workflow, the customer is redirected to preload page hosted on the payment platform before redirection to issuer's Access Control Service (ACS) page. Alternatively, if your web service uses the new scheme implemented in the 3‑D Secure 2 authentication workflow, no such redirection occurs.
• If the issuer chooses the challenge flow, the customer is redirected to issuer's ACS page. If the issuer chooses the challenge flow, such redirection is not performed.

Customers may be offered to choose authentication method, for example the issuer may request the customer to confirm their identity by using biometric data.

What are the procedures for handling customer's biometric data?

3‑D Secure 2 can use biometric data to authenticate customers. This functionality requires that both issuer and customer device are capable to store and process biometric data. Note, though, that it is issuer who—at its own discretion—determines the customer authentication procedure and the authentication options.

Customer authentication by using fingerprint reader or facial recognition system (such as Face ID) on customer's mobile device is example of using biometric data.

Can I find out in advance whether customer must be authenticated?

No, the information about the possibility of customer authentication is stored on the 3DS Server, and therefore this information can only be obtained after sending a payment request.

Are there any payments that do not require the 3‑D Secure 2 authentication?

Yes, the following payments that lie outside of the PSD2 scope:

• Payments with cards issued outside of EEA
• Payment with anonymous prepaid cards such as gift card or prepaid virtual card
• Merchant-initiated transactions (MIT) in which the initial transaction included the 3‑D Secure 2 authentication procedure regardless of the flow type—challenge flow or frictionless flow.

The payment platform detects these payments and omits the authentication procedure when processing these payments.

Optionally, issuer may also choose not to require 3‑D Secure 2 for exemptions such as the following payments:

• Purchases below €30, if after the last 3‑D Secure 2 authentication procedure the customer made no more than five payments totaling no more than €100.
• Low-risk payments that comply with the PSD2 regulations.
• Payments to merchants that are included in cardholder's trusted beneficiaries list.
• Secure corporate payments that are initiated by payers who are not consumers and use dedicated corporate processes and protocols that national competent authorities consider sufficiently secure.

Currently, the Rocketpay payment platform does not supports these exemptions.

Can I altogether avoid 3‑D Secure 2 authentication when performing payments that are exempt from 3‑D Secure 2?

No, this is not necessarily true. It is up to the issuer to decide whether 3‑D Secure 2 authentication is required. The issuer may respond with a soft decline after which the merchant will be required to resend the payment request with the same payment parameters as in the initial request to perform the 3‑D Secure 2 authentication.

What is required to implement 3‑D Secure 2?

To implement 3‑D Secure 2 in your web service, you need to do the following:

1. Contact your Rocketpay account manager and discuss the possibility of implementing 3‑D Secure 2 and the implementation time and schedule.
2. Update your web service to support 3‑D Secure 2.
3. Test and deploy the 3‑D Secure 2 support with Rocketpay support service assistance.

How does the implementation of 3‑D Secure 2 affect the Payment Page payments?

There is no immediate need for merchants to update their web service to comply with the 3‑D Secure 2 procedures, although to increase probability of selecting the frictionless flow, it is recommended that merchants implement the functionality for parsing new parameters and use additional customer parameters in requests for opening Payment Page. Apart from that, the communication with the payment platform remains the same.

Do you offer test cards to set up and debug the new workflow?

To implement and debug your payment procedures that use the new authentication workflow, you can use the following test cards:

Visa cards:

• frictionless flow authentication:
  • 4477 0000 0000 0006—successful payment (payment status: success)
  • 4012 0000 0002 0063—declined payment (payment status: decline)
• challenge flow authentication:
  • 4314 2200 0000 0056—successful payment (payment status: success)
  • 4012 0000 0002 0089—declined payment (payment status: decline)

Mastercard cards:

• frictionless flow authentication:
  • 5252 0000 0000 0004—successful payment (payment status: success)
  • 5544 3300 0000 0029—declined payment (payment status: decline)
• challenge flow authentication:
  • 5413 3300 0000 0019—successful payment (payment status: success)
  • 5544 3300 0000 0045—declined payment (payment status: decline)

If you have any questions regarding test payments, contact our technical support at support@rocketpay.kz.

Can I use 3‑D Secure 2 for all payments with Visa, Mastercard, and Maestro cards?

No, support of 3‑D Secure 2 depends on the issuer and provider readiness to implement the new authentication procedure. From the 14 September 2019, the expectation is for all e-commerce payments in European Economic Area (EEA) to be processed by using 3‑D Secure 2 to meet the Strong Customer Authentication (SCA) requirements. The issuers in other regions are expected to support 3‑D Secure 2 by the end of 2020.

Do I need to support 3‑D Secure 1 if I use 3‑D Secure 2?

Yes, you do need to support the 3‑D Secure 1 authentication, since in some cases an issuer or a provider may prefer 3‑D Secure 1 because the 3‑D Secure 2 is not possible or feasible. For instance, Mastercard allows payment platform to fall back to 3‑D Secure 1 and retry the authentication procedure, if the 3‑D Secure 2 authentication fails due to unavailability of payment system or issuer.

Can merchant choose to use 3‑D Secure 1 instead of 3‑D Secure 2?

No, the decision as to protocol choice belongs solely to the 3DS Server and depends on available issuer facilities. There is no way the merchant can affect the protocol choice.

In the Rocketpay payment platform, you can use the 3‑D Secure 2 authentication in one-step and two-step payments with cards and in payment card verification.

The 3‑D Secure 2 authentication requires you to send a request with the required parameters and the signature to the Rocketpay interface URL and accept the callback with payment result.

If the 3‑D Secure 2 authentication procedure fails because the payment system or the issuer is unavailable or the issuer does not support 3‑D Secure 2, the payment platform falls back to 3‑D Secure 1 and retries the authentication procedure. This situation does not require any additional effort on the part of the web service, though note that your customer may be confused when receiving both a "payment rejected" message and a new verification code and a "payment was successful" message.

Here is a diagram of the 3‑D Secure 2 authentication workflow in a one-step payment procedure.

Overview

In the 3‑D Secure 2 procedures, payment requests use request standard formats and support parameters (both existing parameters and new ones) that are optional, but it is strongly advised to use them to make selection of frictionless flow more likely.

For detailed description of the standard request formats, see Payment Page API. The new objects and parameters are described in this section.

New parameter: payment_merchant_risk

The payment_merchant_risk parameter is used in Payment Page invocation request. The parameter value is a Base64-encoded string which contains all the purchase details and indication of the preferable authentication flow.

The value for the payment_merchant_risk parameter is generated as follows:

1. Add the purchase details and preferable authentication flow data in a payment JSON object as shown in the following sample.

   Figure: Sample JSON object code

   { 
     "payment": { 
       "reorder":"01",
       "preorder_purchase":"01",
       "preorder_date":"01-10-2019",
       "challenge_indicator":"01",
       "challenge_window":"01",
       "gift_card": { 
         "amount":12345,
         "currency":"USD",
         "count":1
       }
     }
   }

   Table 1. Parameters of the payment object

   Parameter	Type	Description
   challenge_indicator	string	This parameter indicates whether challenge flow is requested for this payment. Possible values: 01—no preferences 02—it is preferable not to use challenge flow 03—challenge flow preferred 04—always use challenge flow 05—do not use challenge flow (risk analysis has been performed by the merchant) 06—do not use challenge flow (use Data Only flow) 07—do not use challenge flow (Strong Customer Authentication has been performed) 08—do not use challenge flow (merchant is included in cardholder's trusted beneficiaries list) 09—always use challenge flow (prompt the cardholder to add merchant to the trusted beneficiaries list)
   challenge_window	string	The dimensions of a window in which authentication page opens. Possible values: 01—250 x 400 px 02—390 x 400 px 03—500 x 600 px 04—600 x 400 px 05—full screen
   preorder_date	string	The date the preordered merchandise will be available. Format: dd-mm-yyyy.
   preorder_purchase	string	This parameter indicates whether cardholder is placing an order for merchandise with a future availability or release date. Possible values: 01—merchandise available in stock 02—future merchandise availability
   reorder	string	This parameter indicates whether the cardholder is reordering previously purchased merchandise. Possible values: 01—first time order 02—reorder
   gift_card—object with information about payment with prepaid card or gift card.
   amount	integer	Amount of payment with prepaid or gift card denominated in minor currency units.
   currency	string	Currency of payment with prepaid or gift card in the ISO 4217 alpha-3 format, for example GBP.
   count	integer	Total number of individual prepaid or gift cards/codes used in purchase.

2. Encode the JSON object by using the Base64 scheme.

   Figure: Sample Base64-encoded string

   eyAKICAicGF5bWVudCI6eyAKICAgICJyZW9yZGVyIjoiMDEiLAogICAgInByZW9yZGVyX3B1cmNoYXNlIjoiMDEiLAogICAgInByZW9yZGVyX2RhdGUiOiIwMS0xMC0yMDE5IiwKICAgICJjaGFsbGVuZ2VfaW5kaWNhdG9yIjoiMDEiLAogICAgImNoYWxsZW5nZV93aW5kb3ciOiIwMSIsCiAgICAiZ2lmdF9jYXJkIjp7IAogICAgICAiYW1vdW50IjoxMjM0NSwKICAgICAgImN1cnJlbmN5IjoiVVNEIiwKICAgICAgImNvdW50IjoxCiAgICB9CiAgfQp9Cg==

This string is passed as the value of the payment_merchant_risk parameter which is included amongst other parameters in Payment Page invocation request.

New parameter: customer_account_info

The customer_account_info parameter is used in Payment Page invocation request. The parameter value is a Base64-encoded string which contains customer account details and customer contact information on record with the web service.

The value for the customer_account_info parameter is generated as follows:

1. Add the customer account details and customer contact information data in a customer JSON object as shown in the following sample.

   { 
     "customer": { 
       "address_match":Y,
       "home_phone":"79105211111",
       "work_phone":"74955211111",
       "account": { 
         "additional":"gamer12345",
         "age_indicator":"01",
         "date":"01-10-2019",
         "change_indicator":"01",
         "change_date":"01-10-2019",
         "pass_change_indicator":"01",
         "pass_change_date":"01-10-2019",
         "purchase_number":12,
         "provision_attempts":16,
         "activity_day":22,
         "activity_year":222,
         "payment_age_indicator":"01",
         "payment_age":"01-10-2019",
         "suspicious_activity":"01",
         "auth_method":"01",
         "auth_time":"01-10-201913:12",
         "auth_data":"login_0102"
       }
     }
   }

   Table 2. Parameters of the customer object

   Parameter	Type	Description
   address_match	string	The parameter indicates whether the customer billing address matches the address specified in the shipping object. Possible values: Y—matches N—does not match
   home_phone	string	Customer home phone number. Numeric, from 4 to 24 characters. Example: 44991234567.
   work_phone	string	Customer work phone number. Numeric, from 4 to 24 characters. Example: 44997654321.
   account—object with account information on record with merchant
   additional	string	Additional customer account information, for instance arbitrary customer ID. Maximum 64 characters.
   activity_day	integer	Number of card payment attempts in the last 24 hours. Maximum 3 characters (999).
   activity_year	integer	Number of card payment attempts in the last 365 days. Maximum 3 characters (999).
   age_indicator	string	Number of days since the customer account was created. Possible values: 01—guest check-out 02—customer account was created in this transaction 03—customer account was created less than 30 days ago 04—customer account was created 30 to 60 days ago 05—customer account was created over 60 days ago
   auth_data	string	Any additional log in information in free text. Maximum 255 characters.
   auth_method	string	Authentication type the customer used to log on to the account when placing the order. Possible values: 01—no authentication 02—log on by using authentication data on file with merchant 03—log on by using federated ID (for example, Google Account or Facebook) 04—log on by using a FIDO authenticator (Fast IDentity Online)
   auth_time	string	Account log on date and time. Format: dd-mm-yyyyhh:mm.
   date	string	Account creation date. Format: dd-mm-yyyy.
   change_date	string	Last account change date except for password change or password reset. Format: dd-mm-yyyy.
   change_indicator	string	Number of days since last customer account update, not including password change or reset. Possible values: 01—updated in this transaction 02—updated less than 30 days ago 03—updated 30−60 days ago 04—updated over 60 days ago
   pass_change_date	string	Last password change or password reset date. Format: dd-mm-yyyy.
   pass_change_indicator	string	Number of days since the last password change or reset. Possible values: 01—password never changed 02—changed in this transaction 03—changed less than 30 days ago 04—changed 30−60 days ago 05—changed over 60 days ago
   payment_age	string	Card record creation date. Format: dd-mm-yyyy.
   payment_age_indicator	string	Number of days since the payment card details were saved in a customer account. Possible values: 01—current payment uses no customer account (guest checkout) 02—card details were saved today 03—card details were saved less than 30 days ago 04—card details were saved 30 to 60 days ago 05—card details were saved more than 60 days ago
   provision_attempts	integer	Number of attempts to add card details in customer account in the last 24 hours. Maximum 3 characters (999).
   purchase_number	integer	Number of purchases with this cardholder account in the previous six months. Maximum 4 characters (9999).
   suspicious_activity	string	Suspicious activity detection result. Possible values: 01—no suspicious activity detected 02—suspicious activity detected

2. Encode the JSON object by using the Base64 scheme.

   Figure: Sample Base64-encoded string

   eyAKICAiY3VzdG9tZXIiOnsgCiAgICAiYWRkcmVzc19tYXRjaCI6dHJ1ZSwKICAgICJob21lX3Bob25lIjoiNzkxMDUyMTExMTEiLAogICAgIndvcmtfcGhvbmUiOiI3NDk1NTIxMTExMSIsCiAgICAiYWNjb3VudCI6eyAKICAgICAgImFkZGl0aW9uYWwiOiJnYW1lcjEyMzQ1IiwKICAgICAgImFnZV9pbmRpY2F0b3IiOiIwMSIsCiAgICAgICJkYXRlIjoiMDEtMTAtMjAxOSIsCiAgICAgICJjaGFuZ2VfaW5kaWNhdG9yIjoiMDEiLAogICAgICAiY2hhbmdlX2RhdGUiOiIwMS0xMC0yMDE5IiwKICAgICAgInBhc3NfY2hhbmdlX2luZGljYXRvciI6IjAxIiwKICAgICAgInBhc3NfY2hhbmdlX2RhdGUiOiIwMS0xMC0yMDE5IiwKICAgICAgInB1cmNoYXNlX251bWJlciI6MTIsCiAgICAgICJwcm92aXNpb25fYXR0ZW1wdHMiOjE2LAogICAgICAiYWN0aXZpdHlfZGF5IjoyMiwKICAgICAgImFjdGl2aXR5X3llYXIiOjIyMjIsCiAgICAgICJwYXltZW50X2FnZV9pbmRpY2F0b3IiOiIwMSIsCiAgICAgICJwYXltZW50X2FnZSI6IjAxLTEwLTIwMTkiLAogICAgICAic3VzcGljaW91c19hY3Rpdml0eSI6IjAxIiwKICAgICAgImF1dGhfbWV0aG9kIjoiMDEiLAogICAgICAiYXV0aF90aW1lIjoiMDEtMTAtMjAxOTEzOjEyIiwKICAgICAgImF1dGhfZGF0YSI6ImxvZ2luXzAxMDIiCiAgICB9CiAgfQp9

This string is passed as the value of the customer_account_info parameter which is included amongst other parameters in Payment Page invocation request.

New parameter: customer_shipping

The customer_shipping parameter is used in Payment Page invocation request. The parameter value is a Base64-encoded string which contains shipping details.

The value for the customer_shipping parameter is generated as follows:

1. Add the shipping details in a shipping JSON object and then insert it into a customer object as shown in the following sample.

   Figure: Sample JSON object code

   { 
     "customer": { 
       "shipping": { 
         "type":"01",
         "delivery_time":"01",
         "delivery_email":"test@example.com",
         "address_usage_indicator":"01",
         "address_usage":"01-10-2019",
         "city":"Moscow",
         "country":"RU",
         "address":"Main street 12",
         "postal":"109111",
         "region_code":"RU",
         "name_indicator":"01"
       }
     }
   }

   Table 3. Objects and parameters for the customer_shipping parameter

   Parameter	Type	Description
   shipping—object that contains shipment details
   address	string	Shipping address. Maximum 150 characters.
   address_usage	string	First shipping address usage date in the dd-mm-yyyy format.
   address_usage_indicator	string	Number of days since the first time usage of the shipping address. Possible values: 01—this transaction 02—less than 30 days ago 03—30−60 days ago 04—more than 60 days ago
   city	string	Shipping city. Maximum 50 characters.
   country	string	Shipping country in the ISO 3166-1 alpha-2 format, for example GB for United Kingdom of Great Britain and Northern Ireland.
   delivery_email	string	The email to ship purchased digital content if the customer chooses email delivery. Maximum 255 characters.
   delivery_time	string	Shipment terms. Possible values: 01—digital delivery 02—same-day delivery 03—overnight delivery 04—longer than overnight delivery
   name_indicator	string	Shipment recipient flag. 01—customer and shipment recipient are the same person 02 —customer and shipment recipient are different persons
   postal	string	Shipping postbox number. Maximum 16 characters.
   region_code	string	State, province, or region code in the ISO 3166-2 format. Example: SPE for Saint Petersburg, Russia. If you specify this parameter, you also need to specify and populate the country parameter in the shipping object.
   type	string	Shipment indicator. Possible values: 01—ship to cardholder billing address 02—ship to another verified address on file with merchant 03—ship to address that is different from the cardholder billing address or any verified address on file with merchant 04—ship to local store 05—digital goods shipment 06—no shipment, for instance for travel or event tickets 07—other, for example gaming or subscriptions

2. Encode the JSON object by using the Base64 scheme.

   Figure: Sample Base64-encoded string

   eyAKICAiY3VzdG9tZXIiOnsgCiAgICAic2hpcHBpbmciOnsgCiAgICAgICJ0eXBlIjoiMDEiLAogICAgICAiZGVsaXZlcnlfdGltZSI6IjAxIiwKICAgICAgImRlbGl2ZXJ5X2VtYWlsIjoidGVzdEBnbWFpbC5jb20iLAogICAgICAiYWRkcmVzc191c2FnZV9pbmRpY2F0b3IiOiIwMSIsCiAgICAgICJhZGRyZXNzX3VzYWdlIjoiMDEtMTAtMjAxOSIsCiAgICAgICJjaXR5IjoiTW9zY293IiwKICAgICAgImNvdW50cnkiOiJSVSIsCiAgICAgICJhZGRyZXNzIjoiTGVuaW5hIHN0cmVldCAxMiIsCiAgICAgICJwb3N0YWwiOiIxMDkxMTEiLAogICAgICAicmVnaW9uX2NvZGUiOiJSVSIsCiAgICAgICJuYW1lX2luZGljYXRvciI6IjAxIgogICAgfQogIH0KfQ==

This string is passed as the value of the customer_shipping parameter which is included amongst other parameters in Payment Page invocation request.

New parameter: customer_mpi_result

The customer_mpi_result parameter is used in Payment Page invocation request. The parameter value is a Base64-encoded string which contains the information about the previous authentication attempt of the current customer.

1. Add the previous authentication attempt data in a mpi_result JSON object and then insert it into a customer object as shown in the following sample.

   Figure: Sample JSON object code

   { 
     "customer": { 
       "mpi_result": { 
         "acs_operation_id":"00000000-0005-5a5a-8000-016d3ea31d54",
         "authentication_flow":"01",
         "authentication_timestamp":"201812141050"
       }
     }
   }

   Table 4. Objects and parameters for the customer_mpi_result parameter

   Parameter	Type	Description
   mpi_result—object that contains information about previous customer authentication
   acs_operation_id	string	The ID the issuer assigned to the previous customer operation and returned in the acs_operation_id parameter inside the callback with payment processing result. Maximum 36 characters.
   authentication_flow	string	The flow the issuer used to authenticate the cardholder in the previous operation and returned in the authentication_flow parameter of the callback with payment processing results. Possible values: 01—frictionless flow 02—challenge flow
   authentication_timestamp	string	Date and time of the previous successful customer authentication as returned in the mpi_timestamp parameter inside the callback message with payment processing result.

2. Encode the JSON object by using the Base64 scheme.

   Figure: Sample Base64-encoded string

   eyAKICAiY3VzdG9tZXIiOnsgCiAgICAibXBpX3Jlc3VsdCI6eyAKICAgICAgImFjc19vcGVyYXRpb25faWQiOiIwMDAwMDAwMC0wMDA1LTVhNWEtODAwMC0wMTZkM2VhMzFkNTQiLAogICAgICAiYXV0aGVudGljYXRpb25fZmxvdyI6IjAxIiwKICAgICAgImF1dGhlbnRpY2F0aW9uX3RpbWVzdGFtcCI6IjIwMTgxMjE0MTA1MCIKICAgIH0KICB9Cn0=

This string is passed as the value of the customer_mpi_result parameter which is included amongst other parameters in Payment Page invocation request.

Existing parameters involved in authentication flow selection

To make selection of the frictionless flow authentication more likely, we recommend that you use some of the existing parameters—in addition to the new ones that are described in the previous sections. The following table describes the existing parameters of the customer object you can use to facilitate authentication.

These parameters are described in greater details here: Payment Page invocation parameters.

The payment platform sends to your web service a callback with customer redirection data as described in more details in Callbacks in Gate.

If the payment processing uses the 3‑D Secure 2 authentication, callbacks may contain the mpi_result object which includes the following parameters:

• mpi_operation_id—operation ID on the 3DS Server side
• ds_operation_id—operation ID on the Directory Server side of the global payment system
• acs_operation_id—operation ID on the Access Control Server of the issuer
• mpi_timestamp—authentication time and date
• cardholder_info—a copy of the message it is recommended to display when notifying the customer about the authentication result
• authentication_flow—challenge flow indicator: 01 for frictionless flow, 02 for challenge flow.

To implement the receipt of these parameters, contact the support service at support@rocketpay.kz

{
  "account": {
    "number": "424242******4243",
    "token": "f365bb1729f9b72fd9c09703a751c979f3becc679f29c3e35c91d18070d15654",
    "type": "visa",
    "card_holder": "JUDY DOE",
    "id": 45678,
    "expiry_month": "08",
    "expiry_year": "2025"
  },
  "customer": {
    "id": "customer_12",
    "phone": "44991234567"
  },
  "payment": {
    "date": "2019-01-11T13:02:42+0000",
    "id": "456789",
    "method": "card",
    "status": "success",
    "sum": {
      "amount": 400000,
      "currency": "USD"
    },
    "type": "purchase",
    "description": ""
  },
  "project_id": 42,
  "operation": {
    "id": 969000002636,
    "type": "sale",
    "status": "success",
    "date": "2019-01-11T13:02:42+0000",
    "created_date": "2019-01-11T13:01:45+0000",
    "request_id": "c6eed1eb14c629b4ef20b3b8086d...d04132c34b0088cbc0be4667c",
    "sum_initial": {
      "amount": 400000,
      "currency": "USD"
    },
    "sum_converted": {
      "amount": 400000,
      "currency": "USD"
    },
    "provider": {
      "id": 408,
      "payment_id": "330157196",
      "date": "2019-01-11T13:02:32+0000",
      "auth_code": "",
      "endpoint_id": "612266625"
    },
    "mpi_result": {
      "mpi_operation_id": "",  // Operation ID on the 3DS Server side
      "ds_operation_id": "",   // Operation ID on the Directory Server of the global payment system 
      "acs_operation_id": "",  // Operation ID on the Access Control Server of the issuer
      "mpi_timestamp": "YYYYMMDDHHMM",  // Authentication timestamp
      "cardholder_info": "Additional authentication is needed for this transaction, 
           contact (Issuer Name) at..", // Copy of the message customer received after authentication 
      "authentication_flow":"02" // Challenge flow indicator
    },
    "code": "0",
    "message": "Success",
    "eci": "07"
  },
  "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...=="
}