A Braintree access token lets its holder act for a merchant account through the Braintree gateway API. The actions allowed depend on the scope the merchant granted when the token was issued. In practice that can mean creating charges, issuing refunds, reading customer and transaction data, and changing payment settings. Money moves on the merchant’s account, so a leaked token is a direct payment risk, not only a data risk. Revoke it first, then check the money.
Check your GitHub account for leaked secrets — free
- Provider
- PayPal Braintree
- Severity
- Critical
- Impact
- Payments and customer data
- Checked live by LeakWatch
- No
What a Braintree Access Token looks like
A production Braintree access token has a fixed structure. It starts with the literal text access_token, then the environment name production, then a 16-character merchant identifier made of lowercase letters and digits, and finally 32 hexadecimal characters. The parts are joined by dollar signs:
access_token$production$…XXXX$… Braintree access token (masked)
The merchant identifier in the middle is useful. It tells you which merchant account the token belongs to, so you know which Control Panel to open. Tokens for the sandbox environment use the same structure with a different environment name. The rule in LeakWatch matches only the production form, so a sandbox token in the same file will not be reported by this rule.
How Braintree access tokens get leaked
- Partner integration code. A platform that connects merchants through OAuth stores each merchant’s access token in a database or a configuration file, and a copy ends up in a repository.
- Server configuration. A Braintree server SDK setup, or a configuration file for a payment module, committed with the token inline.
- Pipeline output. A deployment step that prints its environment, or a debug log that records the full gateway request.
- Support requests. A token pasted into a ticket, a chat thread or a forum post to debug a failing charge.
- Copied examples. A tutorial or example project that was edited to use a real token and then published.
What to do in the first hour
- Identify the merchant. Read the merchant identifier from the token, which is the 16 characters between the first two dollar signs after
production. Use it to find the right merchant account and the Control Panel for it. - Revoke the token. The merchant can revoke access from the Control Panel. If your platform issued the token, it can also call the gateway’s revoke-access-token method, which the Braintree developer documentation describes. Do this before you do anything else, because it stops further calls at once.
- Reauthorize the integration. Run the same OAuth flow your integration uses to get a new access token. Store the new value in a secret manager, not in the code.
- Confirm the replacement. Run one read-only request, such as searching for recent transactions, to confirm the new token works.
- Review transactions. Search for transactions, refunds and voids since the exposure. Look for charges you did not start, refunds to unknown payment methods, and unusual amounts.
- Check payout and account details. Confirm that the bank account payouts go to is the one you expect, and that the contact and settings details on the merchant account have not changed.
- Check the webhooks and notification endpoints. Make sure notifications go only to your own servers. Remove any endpoint you do not recognize.
- Clean the repository. Remove the value from the code, rewrite history if needed, and look for other secrets nearby. See I accidentally pushed an API key to GitHub.
Not sure what else leaked? Run a free scan.
Revoke it at PayPal Braintree
Revocation is done from the Control Panel of the merchant the token belongs to. Open the access settings for the connected account and revoke the token there, using the access settings in the Control Panel as the place to start. Your platform can also revoke the token through the API, which is the usual route for a partner integration. Once it is revoked, calls made with it return an authentication error. If your integration subscribes to the OAuth access revoked webhook, you will also be told when this happens. The exact menu names change over time, so if the page looks different, look for the section that manages connected access or OAuth access for the account.
How LeakWatch detects it
The rule is called PayPal Braintree Access Token. It matches the literal text access_token$production$, followed by 16 lowercase letters or digits, another dollar sign, and 32 lowercase hexadecimal characters. The match is case sensitive and must follow that exact structure, so a token with a sandbox environment or a changed separator is not reported. The severity is critical, because the token can move money. This type is not checked live: LeakWatch does not send any request to Braintree with the token it found.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
Can someone take money out of my account with this token?
They can do what its scope allows. Depending on the scope granted, that can include charges and refunds. Refunds to a card or account the attacker controls are the most common loss, so review refunds first.
Is revoking enough, or do I need to change anything else?
Revoking stops the token, but you must still reauthorize the integration to restore service, and you should review what the token did while it was valid. Check transactions, payouts and notification endpoints as well, because a token is only one part of the setup.
Does the sandbox token need the same response?
Usually it is less urgent, because sandbox transactions are not real money. Still revoke and replace it if it was in the same repository, since a sandbox credential that is leaked can be used to probe your integration.