3D Secure

Testing and Go Liveanchor

Testinganchor

The Braintree sandbox allows end-to-end testing for each of the card brands supported in our 3DS2 integration. The following is a list of test numbers for various card brands:

If you call Transaction.sale() without performing a 3D Secure authentication, the issuing bank may return a soft decline indicating that the issuing bank will not proceed with the transaction without requiring the cardholder to authenticate. In this case, 2099 - Cardholder Authentication Required, or another soft decline code, will be returned. You can simulate this scenario by creating a test transaction in Sandbox with an amount of 2099.

It is recommended to disable ad blockers when using the test cards below. Some ad blockers have been found to prevent device data collection, resulting in a 3DS1 response.

important

For expiration year values for all test cards in the table below, use the current year +3. The expiration month should always be 01. For example, if the current year is currentYear, a valid test value for the expiration date would be 01/exampleExpirationYear 3.

Scenario Card brand specific test values
Successful No-Challenge Authentication
Cardholder enrolled, authentication successful, and signature verification successful.

status: authenticate_successful

Visa

  • 4000000000001000
  • 01/20**
Mastercard
  • 5200000000001005
  • 01/20**
Amex
  • 340000000001007
  • 01/20**
Discover
  • 6011000000001002
  • 01/20**
ELO
  • 6277800000002390
  • 01/20**

Failed No-Challenge Authentication
Cardholder enrolled, authentication unsuccessful. Merchants should prompt customers for another form of payment.

status: authenticate_frictionless_failed

Visa

  • 4000000000001018
  • 01/20**
Mastercard
  • 5200000000001013
  • 01/20**
Amex
  • 340000000001015
  • 01/20**
Discover
  • 6011000000001010
  • 01/20**
ELO
  • 6277800000002457
  • 01/20**

Attempt No-Challenge Authentication
The provided card brand authenticated this 3D Secure transaction without password confirmation from the customer.

status: authenticate_attempt_successful

Visa

  • 4000000000001026
  • 01/20**
Mastercard
  • 5200000000001021
  • 01/20**
Amex
  • 340000000001023
  • 01/20**
Discover
  • 6011000000001028
  • 01/20**
ELO
  • 6277800000002531
  • 01/20**

Unavailable No-Challenge Authentication from the Issuer
Authentication unavailable for this transaction.

status: authenticate_unable_to_authenticate

Visa

  • 4000000000001034
  • 01/20**
Mastercard
  • 5200000000001039
  • 01/20**
Amex
  • 340000000001031
  • 01/20**
Discover
  • 6011000000001036
  • 01/20**
ELO
  • 6277800000002309
  • 01/20**

Rejected No-Challenge Authentication by the Issuer
Authentication unsuccessful. Merchants should prompt customers for another form of payment.

status: authenticate_rejected

Visa

  • 4000000000001042
  • 01/20**
Mastercard
  • 5200000000001047
  • 01/20**
Amex
  • 340000000001049
  • 01/20**
Discover
  • 6011000000001044
  • 01/20**
ELO
  • 6277800000002044
  • 01/20**

Authentication Not Available on Lookup
Authentication unavailable for this transaction.

status: authentication_unavailable

Visa

  • 4000000000001059
  • 01/20**
Mastercard
  • 5200000000001054
  • 01/20**
Amex
  • 340000000001056
  • 01/20**
Discover
  • 6011000000001051
  • 01/20**
ELO
  • 6277800000002135
  • 01/20**

Error on Lookup
An error occurred while attempting to lookup enrollment.

status: lookup_error

Visa

  • 4000000000001067
  • 01/20**
Mastercard
  • 5200000000001062
  • 01/20**
Amex
  • 340000000001064
  • 01/20**
Discover
  • 6011000000001069
  • 01/20**
ELO
  • 6277800000002655
  • 01/20**

Timeout on Lookup
Attempting to lookup enrollment resulted in a timeout.

status: lookup_failed_acs_error

Visa

  • 4000000000001075
  • 01/20**
Mastercard
  • 5200000000001070
  • 01/20**
Amex
  • 340000000001072
  • 01/20**
Discover
  • 6011000000001077
  • 01/20**
ELO
  • 6277800000002820
  • 01/20**

Bypassed Authentication
Bypass used to simulate a scenario where merchant has elected to bypass the consumer authentication flow via CardinalCommerce Rules Engine configuration.

status: lookup_bypassed

Visa

  • 4000000000001083
  • 01/20**
Mastercard
  • 5200000000001088
  • 01/20**
Amex
  • 340000000001080
  • 01/20**
Discover
  • 6011000000001085
  • 01/20**
ELO
  • 6277800000002945
  • 01/20**

Successful Challenge Authentication
Cardholder enrolled, authentication successful, and signature verification successful.

status: authenticate_successful

Visa

  • 4000000000001091
  • 01/20**
Mastercard
  • 5200000000001096
  • 01/20**
Amex
  • 340000000001098
  • 01/20**
Discover
  • 6011000000001093
  • 01/20**
ELO
  • 6277800000002325
  • 01/20**

Failed Challenge Authentication
Cardholder enrolled, authentication unsuccessful. Merchants should prompt customers for another form of payment.

status: challenge_required

Visa

  • 4000000000001109
  • 01/20**
Mastercard
  • 5200000000001104
  • 01/20**
Amex
  • 340000000001106
  • 01/20**
Discover
  • 6011000000001101
  • 01/20**
ELO
  • 6277800000002127
  • 01/20**

Challenge Authentication is Unavailable
Authentication unavailable for this transaction.

status: challenge_required

Visa

  • 4000000000001117
  • 01/20**
Mastercard
  • 5200000000001112
  • 01/20**
Amex
  • 340000000001114
  • 01/20**
Discover
  • 6011000000001119
  • 01/20**
ELO
  • 6277800000002887
  • 01/20**

Error on Authentication
An error occurred while attempting to authenticate. Alternatively, merchants can ask customers for an alternative form of payment.

status: authenticate_error

Visa

  • 4000000000001125
  • 01/20**
Mastercard
  • 5200000000001120
  • 01/20**
Amex
  • 340000000001122
  • 01/20**
Discover
  • 6011000000001127
  • 01/20**
ELO
  • 6277800000002507
  • 01/20**

Data Only Successful
The data-only 3D Secure call was successfully created. The dataOnlyRequested flag must be sent to receive a successful response.

status: data_only_successful

Mastercard

  • 5119737947565580
  • 01/20**

See the guide from CardinalCommerce, our 3DS2 authentication provider, for more details on the test card numbers above.

Go liveanchor

important

Your sandbox account is not linked to your production account in any way. Nothing created in the sandbox will transfer to production. This includes processing options and recurring billing settings. Your login information, merchant ID, and API keys will also be different.

Create an API useranchor

Production API credentials, including your API keys, must be entered into your server-side code to connect API calls to the Braintree gateway. While each user in your gateway has their own unique set of API keys, only one set can be included in your integration.

We do not recommend including an individual user's API credentials. If you ever need to delete or suspend that user, this could break your connection to Braintree and result in failed transactions.

Instead, create a new user specifically designated as the API user, whose API keys can be used for your integration. This user should be set up with an email address that is not associated with a single employee and should have Account Admin permissions in order to avoid issues such as an authorization error.

Get production credentialsanchor

Log into your production account as the API user to obtain your API credentials. You'll need the:

  • Production merchant ID
  • Production public key
  • Production private key

Keep in mind that public and private keys are both environment- and user-specific.

Update production account settingsanchor

Make sure your production account settings mirror the ones in your tested sandbox configuration. Be sure to recreate any recurring billing plans or settings if you plan to use recurring billing in production.

Update live server configurationanchor

In your server code, update your configuration to production values:

  1. Ruby
gateway = Braintree::Gateway.new(
  :environment => :production,
  :merchant_id => "use_your_merchant_id",
  :public_key => "use_your_public_key",
  :private_key => "use_your_private_key",
)

Once you have updated these values and configured your preferred processing settings, the live production environment will function similarly to the sandbox environment you've been using for development. Learn more about the differences between production and the sandbox.

On the client side, no configuration updates are needed when you make the switch to production – your client obtains its client token from your server, which is all the configuration it needs.

Test transactions in productionanchor

It is important to test your production account by creating a couple of low-value sale transactions for each of the payment method types you plan to accept. Be sure to submit the transactions for settlement, and then confirm that the funds have deposited into your bank account. This typically happens a few days after they have settled.

important

Real payment methods must be used in the production environment. Test values from the sandbox testing page will not work. This means that every test transaction that you allow to settle in your production account will debit funds from the associated payment method and fees will be assessed. Be sure to test with reasonable amounts and only run a limited number of transactions.


Next Page: Advanced Options