3D Secure
Testing and Go Live
Testing
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.
importantFor 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
|
| Failed No-Challenge Authentication Cardholder enrolled, authentication unsuccessful. Merchants should prompt customers for another form of payment. status: authenticate_frictionless_failed | Visa
|
| Attempt No-Challenge Authentication The provided card brand authenticated this 3D Secure transaction without password confirmation from the customer. status: authenticate_attempt_successful | Visa
|
| Unavailable No-Challenge Authentication from the Issuer Authentication unavailable for this transaction. status: authenticate_unable_to_authenticate | Visa
|
| Rejected No-Challenge Authentication by the Issuer Authentication unsuccessful. Merchants should prompt customers for another form of payment. status: authenticate_rejected | Visa
|
| Authentication Not Available on Lookup Authentication unavailable for this transaction. status: authentication_unavailable | Visa
|
| Error on Lookup An error occurred while attempting to lookup enrollment. status: lookup_error | Visa
|
| Timeout on Lookup Attempting to lookup enrollment resulted in a timeout. status: lookup_failed_acs_error | Visa
|
| 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
|
| Successful Challenge Authentication Cardholder enrolled, authentication successful, and signature verification successful. status: authenticate_successful | Visa
|
| Failed Challenge Authentication Cardholder enrolled, authentication unsuccessful. Merchants should prompt customers for another form of payment. status: challenge_required | Visa
|
| Challenge Authentication is Unavailable Authentication unavailable for this transaction. status: challenge_required | Visa
|
| 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
|
| 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
|
See the guide from CardinalCommerce, our 3DS2 authentication provider, for more details on the test card numbers above.
Go live
importantYour 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 user
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 credentials
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 settings
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 configuration
In your server code, update your configuration to production values:
- 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 production
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.
importantReal 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 →