Changes to Client Tokens Are Coming

Update (December 3, 2019): Updated production roll out date.

Update (November 21, 2019): Added detail around changing token length.

Update (August 7, 2019): Since posting this we have received a number of support requests about how this change will affect subscription billing or vaulted payment methods. We want to make clear that this change applies only to client tokens, meaning the tokens used to authorize clients such as browsers and mobile apps. This change will not affect any vaulted payment method or recurring billing.

Braintree merchants currently have two different ways to collect payment information through clients (mobile devices, web pages, etc.): tokenization keys and client tokens. To help improve performance and increase security, we will soon be changing the system we use for client tokens.

What’s changing?

In the new system, Braintree will be issuing JSON web tokens (JWTs) as a replacement for the current authorization fingerprint implementation. Our client tokens have always been defined as single use, and this change will enforce a 24-hour lifespan. That means client tokens issued after the change is implemented will expire after 24 hours, and attempts to use an expired token will result in an error. While the change is backwards-compatible and transparent for most, some merchants may have to update their integration to be fully compatible with the new system. If you’re unsure about compatibility, you can test against it now in our sandbox environment.

When will the changes take place?

We plan to roll out this change to 100% of merchants in production on January 6, 2020.

Why are we making these changes?

With the impending regulatory mandate for PSD2: Strong Customer Authentication (SCA) in Europe taking effect in September 2019, and the gradual move toward SCA globally, we anticipate that the relative usage of client tokens will continue to increase over the next few years. We confidently base this assumption on the fact that 3D Secure 2, the industry-standard authentication solution for SCA -- and the one Braintree is suggesting our merchants adopt in order to be SCA-ready -- is only supported by client tokens. As the payments platform solution for the large and fast-growing enterprises that are building the most innovative commerce experiences globally, we felt this was the right time to optimize the way they collect payment information.

What is the benefit for merchants?

For our merchants -- regardless of whether or not they are required to meet SCA requirements -- this change has the benefit of reducing the peak latency of collecting client-side payment information. That should mean faster checkouts, fewer timeouts, and potentially an increase in revenue. Merchants will also have clearer visibility into exactly when a token expires and when a new one is required, helping to reduce accidental errors that could negatively affect conversion.

What action is required?

This change is backwards-compatible, and no action is required for most integrations. Integrations that rely on client tokens remaining valid for longer than 24 hours will need to be updated to ensure that clients are using tokens generated within the last 24 hours. In addition, minor changes in length of the token will occur. If you believe your systems may be affected by this, we recommend testing these changes in sandbox. If you have any questions, contact us.

Joshua Knox Joshua is a software engineer at Braintree. He is the primary author of the Forward API and Grant API. More posts by this author

You Might Also Like