Testing and Go Live

RubySDK

• Current Braintree SDKs
• Java
• .NET
• Node.js
• PHP
• Python
• Ruby

To test recurring billing functionality in sandbox:

1. Store a payment method in your sandbox using the test values below
2. Create a plan
3. Create a subscription

Test values

Nonces representing cards

You can use any of the nonces in this table to simulate a card transaction or trigger a successful card verification response.

note

When testing card verifications and transactions, keep in mind:

• Transaction success is determined by the test amount you use
• Verification success is determined by the test nonce you use

Nonces representing alternative payment methods

Nonces for testing card verification

Processor rejected nonces

The following payment method nonces represent credit cards that simulate an unsuccessful card verification response with a status of processor_declined.

Gateway rejected nonces

The following payment method nonces represent credit cards that simulate an unsuccessful card verification response with a status of gateway_rejected.

CVV-only nonces

The following payment method nonces represent credit card CVV or CID values collected on the client side to verify cards already stored in your Vault. The test nonce you use determines which cvv_response_code you receive in the sandbox.

For details on generating CVV-only nonces in your client-side integration, see the client SDK references:

• Android client reference
• iOS client reference
• JavaScript v3 client reference
• JavaScript v2 client reference

3D Secure nonces and authentication IDs

You can use these nonces or authentication IDs to test your integration under various 3D Secure scenarios for Visa cards. Authentication IDs are an alternate way of specifying a 3D Secure authentication to use for a transaction if no authentication is attached to the payment method. See the 3D Secure guide for more information on different status codes.

note

The following nonces are only for testing Visa cards. Liability shift status is generally agnostic to the card type and other card brands will work similarly.

Nonce objects

When writing integrations tests against the Braintree sandbox environment, you may also use these nonce objects in place of the nonce that would normally be returned from the client side integration.

Braintree::Test::Nonce::Transactable
Braintree::Test::Nonce::Consumed
Braintree::Test::Nonce::PayPalOneTimePayment
Braintree::Test::Nonce::PayPalFuturePayment

You can also use the test credit card values in the Testing Reference page.

Go live

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

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.

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.

See also

• Recurring billing validation error