Premium Fraud Management Tools

Testing and Go Liveanchor

Try out your fraud tools integration in the sandbox with these test values:

You can use the following test card number in the sandbox to simulate Premium Fraud Management Tools flagging a transaction as pending review. This feature is only available for Fraud Protection Advanced.

Card TypeTest ValueStatusDecision

You can use the following test card numbers in the sandbox to simulate Premium Fraud Management Tools or risk threshold rules rejecting a request.


In order to access the Risk Threshold gateway rejection reason, you must use at least the version indicated below.

  • Java 3.1.0
  • .NET 5.0.0
  • Node 2.24.0
  • PHP 5.3.0
  • Python 4.3.0
  • Ruby 2.103.0

Otherwise, you will receive an Unrecognized status for the gateway rejection.

Card TypeTest ValueStatusReason

The Dashboard/User Interface of Fraud Protection and Fraud Protection Advanced is only for illustrative purposes in sandbox. You will not be able to tweak any settings to reject transactions. For testing transaction rejections, please use the test value for the card number as defined above.

The following payment method nonces represent payment methods that will be gateway rejected by Braintree's various fraud tools.

fake-gateway-rejected-kount-nonceA nonce representing a card that will be gateway rejected by Kount. The fake-gateway-rejected-kount-nonce will only work if Premium Fraud Management Tools are enabled.
fake-gateway-rejected-risk-thresholds-nonceA nonce representing a card that will be gateway rejected by your risk threshold rules. The fake-gateway-rejected-risk-thresholds-nonce will only work if at least one risk threshold rule is enabled

fake-gateway-rejected-fraud-nonce represents a card that will be gateway rejected by Braintree's fraud tools. This is now deprecated.

Go liveanchor


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 =
  :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.


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.

Keep in mind that if you run too many test transactions in a short period of time, your Premium Fraud Management Tools may start gateway rejecting the transactions due to fraud concerns. To avoid this, do not use more than two different card numbers to test your production account from the same IP address.