Auto 3-D Secure Step-up

What is Auto 3-D Secure Step-up?

Auto 3-D Secure (3DS) is a BR-DGE feature that is designed to maximise your payment approval rates by intelligently handling 3-D Secure "soft declines".

The Auto 3-D Secure Step-Up feature works in the following way:

  1. First Attempt (No 3DS): BR-DGE first attempts to process the payment as a standard, non-3D Secure transaction.
  2. Automatic Re-Attempt (Step-Up to 3DS): If the PSP, or the card issuer, explicitly requests 3DS (for reasons such as Strong Customer Authentication (SCA), or high-risk scoring), the initial attempt will return a soft decline. Instead of returning a 4278 - Customer Authentication Required, response code, BR-DGE will capture the decline and immediately re-triggers a second payment attempt, this time processing the payment with the required 3DS data.

This automated "step-up" ensures the transaction doesn't simply fail. Instead, transitions to the necessary authentication protocol, giving the cardholder the chance to authenticate and complete the purchase.

How to use Auto 3-D Secure Step Up?

This functionality is available on both the POST /v1/orders and /v1/payments API, as a boolean flag under the threeDSecureOptions object.

API Field NameTypeDescription
threeDSecureOptions.automaticallyStepUpbooleanAttempt a payment without 3DS, and if 3DS is requested from the PSP, automatically re-attempt the payment with 3DS enabled.

Example API Requests

POST /v1/payments

{
    "amount": 24000,
    "channel": "ios",
    "currencyCode": "GBP",
    "customerOrderCode": "123456",
    "orderDescription": "Taxi fare",
    "paymentInstrument": {
        "type": "card",
        "nameOnCard": "John Doe",
        "pan": "4444 3333 2222 1111",
        "expiryDate": "03-30",
        "cv2": "123",
        "tokenize": true
    },
    "threeDSecureOptions": {
        "automaticallyStepUp": true
    }
}

POST /v1/orders

{
    "amount": 15000,
    "merchantTransactionId": "{{$guid}}",
    "channel": "ios",
    "currencyCode": "GBP",
    "customerEmail": "[email protected]",
    "customerFirstName": "customerFirstName",
    "customerIpAddress": "1.1.1.2",
    "customerLastName": "customerLastName",
    "customerOrderCode": "{{$guid}}",
    "customerPhoneNumber": "+44 456 1113000",
    "customerSessionId": "123456",
    "orderDescription": "Taxi fare",
    "returnUrl": "https://example.com",
    "threeDSecureOptions": {
        "automaticallyStepUp": true
    }
}

Check out our API Reference for a full overview of the API.

When you set automaticallyStepUp to true, you can expect one of the following outcomes:

  1. Approved on First Attempt (No 3DS): The payment is approved immediately without any action needed from the cardholder. Your system receives a final approval response.
  2. 3-D Secure Required: BR-DGE re-attempts the payment with 3DS and drops you into the BR-DGE 3DS flow. See here for more information on BR-DGE’s 3-D Secure flow.

When to use Auto 3-D Secure Step-up?


Scenario

Recommendation

Rationale

Using BR-DGE’s Hosted Payments Page.

– Use it

If you include auto 3DS step up on your orders, then you do not need to recreate another order in the event of a 4278 response from BR-DGE.

Using a single-use token to make payments

– Use it

BR-DGE’s single token only works for a single payment attempt. In the event of a 4278 response code, you will need to request the card details again to create another single use token

SCA/PSD2 Context

– Use it

For payments in regions like the EEA/UK, the bank may not always require SCA for low-value or low-risk transactions. This feature tries the non-3DS path first, only stepping up when SCA is strictly mandated by the issuer.

Merchant Initiated Transactions

– Avoid it

Merchant Initiated Transaction do not require 3-D Secure.

MOTO payments

– Avoid it

MOTO payments do not require 3DS, given the nature of MOTO payments and their lack of cardholder interaction.

Looking for Liability Shift

– Avoid it

3DS is required for a liability shift to occur. If you want a liability shift without the customer having to authenticate themselves, then challengeRequested should be false instead.

This will attempt a frictionless 3DS flow.