What "Braintree test card v9" actually means

Braintree test card v9 is not a card product and it is not a real account number. The label refers to the set of sandbox test values that Braintree publishes for its testing environment. When a tutorial, ticket, or blog post mentions v9, it points to the current revision of that test-value list. The numbers in the list are fake, they only resolve inside the sandbox, and they let you force a specific response from the gateway so you can build decline handling, retry logic, and receipt flows without moving real money.

read more

If your goal is to reproduce a charge, a decline, or a CVV mismatch on demand, the values below cover the cases most integrations hit. Every one of them is publicly documented by Braintree for sandbox use.

more on this topic

Prerequisites

• A Braintree sandbox account, separate from your production account
• Your sandbox merchant ID, public key, and private key
• A client or API call pointed at the sandbox environment, not production
• Access to the sandbox Control Panel so you can read transaction results

How to run a test transaction

1. Sign in to the sandbox Control Panel and copy the merchant ID, public key, and private key for your sandbox account.
2. Configure your SDK or API client with those credentials and set the environment to sandbox.
3. Pick the test card number that matches the outcome you want to observe.
4. Submit a sale or authorization request with that number, a future expiration date, and any three or four digit CVV.
5. Open the transaction in the Control Panel and read the status, response code, and gateway rejection reason.
6. Repeat with a different number when you need the opposite outcome, such as a processor decline.
7. Keep the same code path for production and swap only the credential set and the environment flag.

Test numbers by expected result

• 4111111111111111, Visa, authorizes successfully
• 4000111111111115, Visa, processor decline
• 5555555555554444, Mastercard, authorizes successfully
• 378282246310005, American Express, authorizes successfully
• 6011111111111117, Discover, authorizes successfully
• 30569309025904, Diners Club, authorizes successfully
• 3530111333300000, JCB, authorizes successfully

CVV and AVS test values

The card number sets the authorization result. Separate test values set the card verification and address verification results. Use CVV 200 to force a CVV mismatch, and use street address 2000 Main Street or postal code 200 to force an AVS mismatch. These values exist so you can verify that your checkout surfaces a verification failure to the customer instead of silently approving the order.

more on this topic

Mistakes that cost time

• Sending sandbox test numbers to the production endpoint, which returns a hard rejection
• Using an expired date, which fails before the card logic runs
• Testing only the success card and never the decline card, which leaves retry handling untested
• Hardcoding test numbers into a release branch
• Assuming a stored test card behaves like a stored real card across environments

A test card is a fixture, not a payment method. Treat the sandbox list as part of your test suite, keep the values in one place in your codebase, and never let a real card number enter your development or staging environment.

related article