When building a web form that has an input for a credit card number, turn off autocomplete so that your customer's browser won't save their credit card number.
<form method="POST" action="..." autocomplete="off">
Most responses from Braintree will include both a code and text. The text is the human-readable description and the code is meant to be consumed programmatically. For example, the processor response on transactions has both a code and text.
result.transaction.processor_response_code #=> "2001" result.transaction.processor_response_text #=> "Insufficient Funds"
If you wanted to build some behavior around transactions that were declined due to insufficient funds (for example, asking the users if they would like to only purchase a subset of items in their cart) you would want to check the code rather than the text. The text may vary as we refine it to provide more clarity or additional details, but the codes will remain consistent.
DOCTYPE declarations that meet W3C standards and review your HTML syntax.
It goes without saying, but we’ll say it anyway: we always recommend using the latest versions of our SDKs. While older versions may still be supported, in order to communicate securely with the Braintree gateway starting June 1, 2018 in sandbox and October 1, 2018 in production, you must use at least the version indicated below.
To verify which version of the Braintree Ruby SDK you’re currently using, run:
bundle show braintree
If you’re ready to update to a newer version of the Ruby SDK, see our recommended approach below.
First, update your Gemfile with the desired version for the Braintree gem. To use the latest version:
gem "braintree", "~> 2.94.0"
Then, update the required Braintree gems:
bundle update braintree
When using the server SDKs, keep in mind that some requests (like creating transactions) can take longer than expected since they rely on communicating with a payment processor. The Braintree gateway has a timeout of 60 seconds to accommodate for this. If you do not want to wait this long, you can set a custom timeout in the server SDKs. However, if this timeout is less than 60 seconds, the request may trigger a timeout exception and you may not see the result of the request.
For example, let's say you set the server SDK timeout to 10 seconds, and you create a transaction sale request. If the request has not completed successfully at 10 seconds, you'll receive a timeout exception. However, if the transaction then completes successfully at 19 seconds, the customer will be charged, but you will not receive any notification of this. You will need to check the state of the transaction in the gateway to verify whether the transaction was successful or not.
gateway = Braintree::Gateway.new( :environment => :sandbox, :merchant_id => "use_your_merchant_id", :public_key => "use_your_public_key", :private_key => "use_your_private_key", :http_read_timeout => 10, :http_open_timeout => 10, )
In order to avoid interruptions in processing, it's best to make minimal assumptions about what our gateway-generated tokens and identifiers will look like in the future. The length and format of these identifiers – including payment method tokens and transaction IDs – can change at any time, with or without advance notice. However, it is safe to assume that they will remain 1 to 64 characters (alphanumeric, dashes, and underscores).
Following the PCI Data Security Standard (PCI DSS) 3.1 requirements, it's critical that you secure your connection to the Braintree gateway using Transport Layer Security (TLS) 1.2 and serve any form that collects payment data in production over HTTPS.
On June 26, 2018, Braintree ended support for server-side API requests via TLS 1.0 and 1.1 in production. The sandbox no longer accepts connections using these older TLS versions as of December 13, 2016.
If you are using older TLS or SSL versions, you may need to upgrade your Braintree SDK versions in addition to upgrading to TLS 1.2. See our full list of TLS 1.2-compatible SDKs on GitHub.
We don't have a specific preferred vendor for TLS/SSL certificates, but we recommend that you stick with a well-known provider (e.g. Network Solutions, GoDaddy). Generally speaking, most certificates will be similar, so it's up to you to determine what fits your needs best.
While you can successfully test our Drop-in UI, Hosted Fields, and client-side PayPal flow over HTTP in all supported desktop and mobile browsers, you must use HTTPS if you wish to test our PayPal button in mobile webviews. Ultimately, we strongly encourage you to test all your flows over HTTPS to create a more realistic test environment.
Still have questions?
If you can’t find an answer, contact us