3DS purchase

Make a purchase payment with 3DS in DEUNA.

1. Generate a payment

To create a payment, you can use the following two flows:

  1. Two-step flow:
    1. Create an order
    2. Create a payment associated with that order
  2. Single-step flow

2. Use the payment response

In the payment response, you can see the following fields that are necessary to know that said charge requires the end user to authenticate:

{
    "order": {
        "order_id": "75029759-4a64-42cd-b0b6-9f12777707b7",
        "currency": "USD",
        "total_amount": 3150,
        // ...
        "status": "pending", // status of the order will be "pending"
        "payment": {
            "data": {
             		// ...
                "method_type": "credit_card",
                "id": "75029759-4a64-42cd-b0b6-9f12777707b7",
                "processor": "kushki",
                "status": "pending_3ds", // note here the payment status
                "authorization_3ds": {
                    "version": "3DS2",
                    "url_challenge": "https://api.stg.deuna.io/transactions/view_challenge?token=01HC0XG8GA2GH5G684QW572507"
                }
            }
        }
    }
}

3DS fields

The important fields to consider are:

  • The order status (order.status) is pending, because it has not been paid yet.
  • The payment status (payment.data.status) is pending_3ds. This status indicates that it's waiting for authentication by the cardholder.
  • For challenge type authentication cases (the user must take an action during authentication) or frictionless (the user is presented with the 3DS flow but doesn't need to take an action), the payment.data.next_action.authorization_3ds.url property will contain the URL of the web page that should be presented to the buyer. For compatibility with previous integrations, it can also be found in the payment.data.authorization_3ds.url_challenge field.

In the Admin portal, go to the Order Details page.

In the Security section, under 3DS, click on 'See details' to view the 3DS response details. The fields are:

Field NameDescription
eciElectronic Commerce Indicator (ECI) is a value returned by the Directory Server and ACS indicating the outcome of authentication requested on transactions for EMV 3-D Secure.
cavvCAVV provides evidence that cardholder authentication occurred or that the merchant attempted authentication. A CAVV is unique for each authentication transaction. For Visa Secure, the AAV is named CAVV.
xidXID, or Transaction ID, is a unique identifier for 3DS transactions, linking it to authentication details and used for tracking and reconciling transactions.
flow_typeIf is Challenge or Frictionless.
three_ds_server_transaction_idThe unique transaction ID generated by the 3D-Secure server, used to track the transaction throughout the authentication process.
aavAccountholder Authentication Value (AAV). Formally called Universal Cardholder Authentication Field (UCAF), applicable for Mastercard and Maestro e-commerce transactions only.
aav_validation_resultThe result of Accountholder Authentication Value (AAV) validation.
three_ds_authentication_responseThe Payer Authentication Response (PARes) Status, a transaction status result identifier. Values: Y – Successful Authentication. N – Failed Authentication. U – Unable to Complete Authentication. A – Successful Stand-In Attempts Transaction.
full_paresThe full/complete (Payer) Authentication Response. It contains (AcqBIN)(MerID)(XID)(Date)(PurchaseAmount)(PAN)(AuthDate)(Status)(CAVV)(ECI).
directory_server_transaction_idUnique identifier generated by the Directory Server to identify a specific 3DS transaction on the DS side.
tokenToken occasionally generated by the PSP (Payment Service Provider).
veres_enrolledResult of the enrollment check. Possible values: Y – Card enrolled or can be enrolled; authentication required; liability shift applies. N – Card not enrolled; proceed with authorization; liability shift applies. U – Unable to authenticate; no liability shift.
three_ds_processing_providerSpecifies who's carrying the 3DS process from DEUNA's perspective. Possible values: 'psp_own' – The native 3DS offering from a PSP. 'deuna' – DEUNA's 3DS offering.
authentication_resultRaw authentication data from the card-issuing bank. Indicates if authentication was successful and if liability shift occurred. Possible values: -1 – Invalid PARes. 0 – Successful validation. 1 – Cardholder is not participating, but the authentication attempt was recorded. 6 – Issuer unable to perform authentication. 9 – Cardholder did not complete authentication.
acs_transaction_idUnique transaction identifier assigned by the ACS to identify a single transaction.
versionVersion of the 3D-Secure protocol (e.g., 2.0, 2.1.0, etc.).
directory_server_idIdentifier of the directory server. The Directory Server enables communication between the 3DS Server and the ACS, validates and routes 3DS messages to authenticate the cardholder.
pares_statusThe Payer Authentication Response (PARes) Status, a transaction status result identifier. Values: Y – Successful Authentication. N – Failed Authentication. U – Unable to Complete Authentication. A – Successful Stand-In Attempts Transaction.

3. Render the url_challenge

Render the url_challenge from the acquirer`s page.

4. Redirect the user

Once authentication is finished, redirect the user to your callback_urls or to a default page.

For Direct API integrations, you are responsible for redirecting the user to that page or in case of mobile opening that page in a webView.

Use of 3DS Next action widget

For Direct API integrations where redirection management is not desired, use the 3DS Next action widget.

Depending on the payment provider and MPI, the URL must be opened in a completely new tab and not in an iFrame. Check with DEUNA to indicate according to the provider you're going to use.

📘

If you use 3DS Next action widget and the payment provider or MPI supports the use of iFrame, ask DEUNA to configure the widget to render as iFrame instead of requiring redirection.

If you use widgets, then the widgets will be responsible for redirection or iFrame rendering and interpreting when the 3DS flow is required.

📘

If you want to use callback_urls, then contact your implementation manager to activate this functionality.

Use of callback_urls:

Configure callbacks in:

  • Forpurchase V1: send the callback_urls in the field specific_fields.callbacks.
  • Forpurchase V2: send the callback_urls in the field callback_urls.

Use of widgets

As your server only responsible for creating the order, the urls can be passed in the callback_urls field.

DEUNA default page

The user is redirected to the following web page if you do not use callback_urls after authentication:

📝

Depending on the issuing bank, different challenge pages are obtained, but the redirection flow remains the same.

Authentication Timeouts

  • During a 3-D Secure flow, shoppers may be asked to complete an authentication challenge—for example, by entering a one-time password or approving the transaction in their banking app. This challenge must be completed within a limited timeframe before it expires.
  • The issuing bank controls the shopper's authentication experience. Most banks set relatively short time windows—typically between 3 and 5 minutes—to encourage prompt action. While the shopper is authenticating, the transaction remains in status pending_3ds.
  • Since challenge timeouts vary between issuing banks, DEUNA allows a maximum of 10 minutes for the authentication process to complete. During this period, the transaction status remains pending_3ds until the shopper either completes or abandons the challenge.
  • If the shopper does not complete the authentication challenge within the allowed timeframe, the transaction will fail due to timeout. In this scenario, the transaction status will be updated to denied, and the shopper must restart the checkout process.

5. Check the final payment status

DEUNA provides two ways to know the final payment status after 3DS authentication:

DEUNA recommends implementing both processes, so that you can either listen to webhooks or use long polling in case the server has intermittency.

Frictionless 3D-Secure

In the frictionless flow, the user is not requested any type of authentication verification when making the payment, since the ACS (Access Control Server) has validated the user's authenticity with the data provided in the purchase.

This provides a smoother experience for the user, increasing the payment approval rate and decreasing fraud.

To execute a successful Frictionless 3D-Secure purchase, collect certain information about the user such as:

  • Full billing address
  • Device fingerprint
  • IP address
  • Browser details
  • Other relevant information about the user.

Example response

{
  "order": {
    "order_id": "75029759-4a64-42cd-b0b6-9f12777707b7",
    "currency": "USD",
    "total_amount": 3150,
    // ...
    "status": "succeeded",
    "payment": {
      "data": {
        // ...
        "method_type": "credit_card",
        "id": "75029759-4a64-42cd-b0b6-9f12777707b7",
        "processor": "kushki",
        "status": "processed"
      }
    }
  }
}

Radar Quality Excellent

The integration is designed to meet Deuna's excellence standards in fraud management and prevention. Send the necessary information to achieve the standard quality.

Radar session

The radar session data is sent automatically in the widgets.

Via API, it must be sent in the following property:

{
  //...
  "device_id": "{{DEVICE_ID}}"
  //...
}
{
  //...
  "anti_fraud_info": {
    "session_id": "{{SESSION_ID}}"
  }
  //...
}

Customer signals

Provide complete user information:

{
  //...
  "email": "{{USER_EMAIL}}",
  "credit_card": {
    "expiry_month": "11",
    "expiry_year": "29",
    "card_number": "4111111111111111",
    "card_holder": "Elon Musk",
    "card_holder_dni": "1234567891",
    "zip": "12345",
    "city": "Ibarra",
    "address1": "Avenida Mariano Acosta & Obispo Alejandro Pasquel Monge, Ibarra, Ecuador",
    "state": "Quito",
    "phone": "+59123456789",
    "country": "Ecuador",
    "card_cvv": "123"
  }
  //...
}
{
	//...
  "payer_info": {
    "email": "{{USER_EMAIL}}"
  },
  "credit_info": {
    "expiry_month": "11",
    "expiry_year": "29",
    "card_number": "4111111111111111",
    "card_holder": "Elon Musk",
    "card_holder_dni": "1234567891",
    "zip": "12345",
    "city": "Ibarra",
    "address1": "Avenida Mariano Acosta & Obispo Alejandro Pasquel Monge, Ibarra, Ecuador",
    "state": "Quito",
    "phone": "+59123456789",
    "country": "Ecuador",
    "card_cvv": "123"
  }
  //...
}

Testing 3DS in sandbox environment

If you want to test 3DS in DEUNA's test mode, then consult your payment service provider's documentation to locate:

  • Test cards
  • Test amounts needed to activate 3DS

Use the test information with your implementation to test 3DS with DEUNA

Error codes

When performing the authentication process with DEUNA's 3DS MPI, different errors can occur. For particular cases where a payment fails due to a specific 3DS flow error, one of these errors ocurred:

Error codeRejection reasonAdditional Details
FAILED_CHALLENGE_AUTHENTICATIONCardholder challenge failedIssuer/bank originates the error; it occurs when the cardholder fails the 3DS challenge (for example, enters wrong OTP, biometric or password); this is the primary code to use when the cardholder does not complete the challenge successfully.
UNAVAILABLE_CHALLENGE_AUTHENTICATIONCardholder authentication is rejected without a challenge by the issuerIssuer/bank originates the error; it happens when the issuer decides not to present a challenge at all (e.g. risk rules or configuration reject the authentication); the cardholder does not actively fail, the issuer rejects before challenge.
UNABLE_ISSUERIssuer unable to perform authenticationIssuer/bank originates the error; it is triggered when the issuer is temporarily unable to perform 3DS (technical issue or unsupported scenario); the cardholder cannot influence the outcome.
ENROLLMENT_CHECK_ERRORSystem error prevented authentication when checking enrollmentDEUNA or the 3DS server side originates the error; it happens when a technical issue occurs while checking if the card is enrolled in 3DS (network, gateway or integration error); the cardholder has no direct responsibility.
AUTHENTICATION_NOT_AVAILABLE_WHEN_CHECKING_ENROLLMENTSystem error prevented authentication when checking enrollmentDEUNA or the 3DS server side originates the error; it is raised when the enrollment check cannot complete and therefore authentication cannot be offered; the cardholder cannot recover by retrying the challenge.
ENROLLMENT_CHECK_TIMEOUTAn error occurred while attempting to check if the cardholder is part of an authentication programDEUNA or the 3DS infrastructure originates the error; it occurs when the enrollment check does not respond in time (timeout to schemes or issuer); the cardholder is waiting but never reaches the challenge step.
UNSUCCESSFUL_FRICTIONLESS_AUTHENTICATIONAuthentication without a challenge by the card issuer failedIssuer/bank originates the error; it happens when a frictionless authentication attempt (no challenge) is evaluated as failed by the issuer; the cardholder does not see a challenge but the authentication is refused.
STAND_IN_FRICTIONLESS_AUTHENTICATION_ATTEMPTEDCardholder is enrolled in 3-D Secure but the card issuer does not support 3-D SecureSchemes or issuer-side configuration originates the situation; it occurs when the card is enrolled but the issuer cannot complete 3DS and a stand‑in decision is used; the cardholder does not interact with a challenge.
UNAVAILABLE_FRICTIONLESS_AUTHENTICATIONAuthentication is unavailableDEUNA or issuer can originate the error depending on where the failure happens; it is used when frictionless authentication cannot be completed due to a technical issue or unsupported flow; the cardholder normally only sees that authentication is unavailable.
REJECTED_FRICTIONLESS_AUTHENTICATIONCardholder authentication is rejected without a challenge by the issuerIssuer/bank originates the error; it is triggered when the issuer rejects the authentication in a frictionless flow (risk decision or rules) without presenting a challenge; the cardholder does not get a chance to authenticate.
TIME_EXPIREDThe time for the user to complete the 3DS authentication flow has expiredDEUNA records the timeout but the behavior is originated by the cardholder or their environment; it happens when the cardholder does not finish the challenge page in time (closes it, abandons or takes too long); this is the main code when the user simply times out without explicitly failing credentials.
CONSUMER_AUTHENTICATION_FAILEDThe transaction may not have been approved by the issuerIssuer/bank originates the decision; it is used as a generic outcome when 3DS completes but the authorization or final result from the issuer is unclear or negative; the cardholder may have passed 3DS but the bank still declines or does not clearly confirm approval.
ERROR_IN_3DS_PROCESSAn error occurred during the 3DS authentication processDEUNA or the 3DS gateway originates the error; it is used when an internal technical problem occurs while processing 3DS (e.g. communication with the 3DS server, parsing responses or caching data fails); the cardholder usually sees a generic error and is not at fault.
WAITING_3DSThe 3DS authentication flow has started and is awaiting completion by the cardholderDEUNA originates the status based on the transaction state; it represents that the challenge has been presented and the cardholder still needs to complete it; if the cardholder abandons the flow this will later end as TIME_EXPIRED or FAILED_CHALLENGE_AUTHENTICATION.
CHALLENGE_FAILEDThe 3DS challenge could not be completed successfullyIssuer/bank and cardholder jointly originate the outcome; it occurs when the cardholder interacts with the challenge but provides invalid or inconsistent data (wrong OTP, denies the push, fails biometrics); this is the code to return whenever the cardholder explicitly fails the challenge step.
TRANSACTION_MAY_NOT_HAVE_BEEN_APPROVEDThe transaction may not have been approved by the issuerIssuer/bank originates the decision; it is used as a generic outcome when 3DS completes but the authorization or final result from the issuer is unclear or negative; the cardholder may have passed 3DS but the bank still declines or does not clearly confirm approval.