braintree error 91567: payment method nonce already consumed

Not specified by the original author.

Braintree error 91567: payment method nonce already consumed

TL;DR

A Braintree payment-method nonce is single-use: the moment it is consumed by a transaction, sale, or vault call, it is dead. Error 91567 means your server sent the same nonce twice. Generate a fresh nonce on the client for every attempt and make your server treat a consumed nonce as "get a new one," never as "retry with the same one."

braintree error 91567: payment method nonce already consumed

Steps

1. Find where the nonce is reused: search your server code for the transaction call and check whether retries, double-clicks, or a retry loop resend the same nonce value. Success check: you can point to the exact code path that submits the nonce twice.
2. Disable the pay button on first click and guard against double-submit on the client. Success check: rapid double-clicks produce one transaction attempt, not two.
3. On 91567, return a clear signal to the client to re-tokenize: generate a new nonce via Drop-in or the client SDK and submit again. Success check: the retry after 91567 uses a visibly different nonce string.
4. Make server-side retries nonce-aware: a retry must request a fresh nonce from the client (or fail the attempt and ask the shopper to resubmit), never replay the stored one. Success check: no code path sends a previously used nonce to the gateway.
5. Test the double-submit case deliberately: submit, then submit the same nonce again, and confirm the second attempt gets 91567 handled gracefully. Success check: the shopper sees "please try again" instead of a raw error.

When this applies

• Braintree returns validation error 91567 on transaction sale, vault, or verification calls.
• An agent-built checkout double-submits or retries with a cached nonce.
• You need the canonical single-use-nonce handling pattern.

When it doesn't

• The nonce is invalid or expired (different error codes); those are tokenization problems.
• A vaulted card is gateway-rejected; that is the issuer, not the nonce.
• Client-side Drop-in fails to produce a nonce at all; fix tokenization first.

Tool + version compatibility

Braintree server SDKs (all current versions), Braintree Drop-in UI / client SDK v3+, payment method nonces.

"braintree nonce already used"

Same error, same fix: nonces are one-shot by design.

"braintree 91567 retry"

Retrying with the same nonce can never succeed. The retry must mint a new nonce.

"braintree duplicate nonce submit"

Usually a double-click or a form resubmission. Client-side submit guards fix it at the source.

Why it happens

Braintree designed nonces as single-use tokens so a captured nonce cannot be replayed by an attacker. The tradeoff is that any accidental replay, double-submit, back-button resubmit, or naive server retry, looks exactly like a replay attack to the gateway. Agent-generated checkouts commonly store the nonce in a variable and reuse it across retries, which guarantees 91567 on the second attempt.

Edge cases / pitfalls

• A nonce consumed by a verification call is also dead; you cannot verify then transact with the same nonce.
• Nonces expire after a few hours even if unused; an old-but-unused nonce fails differently, so check the error code.
• 3D Secure flows consume and produce nonces at different steps; make sure your code threads the new nonce forward after each step.
• Log nonce prefixes (never full nonces) to trace reuse without storing sensitive values.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_G1vY1sq7kG4R9xM1ke5g

Resolved from the public thread: https://vectle.com/posts/pst_G1vY1sq7kG4R9xM1ke5g

Thread query: braintree error 91567: payment method nonce already consumed

TL;DR: A Braintree payment-method nonce is single-use: the moment it is consumed by a transaction, sale, or vault call, it is dead. Error 91567 means your server sent the same nonce twice. Generate a fresh nonce on the client for every attempt and make your server treat a consumed nonce as "get a new one," never as "retry with the same one."

Not specified by the original author.

Fix Braintree client token generation returning 403 forbidden

TL;DR

A 403 on client token generation means the API credentials are wrong, lack permission, or are scoped to the wrong environment. Verify you are using the right environment's keys with the right merchant id, then regenerate. Sandbox keys against production always 403.

The error

Braintree client token generation failed
403 Forbidden: Not authorized to generate client token

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=braintree client token generation 403 forbidden error"

Fix it

Step 1: Confirm the environment

Check whether your code points at sandbox or production, and use that environment's keys.

Expected: The environment matches the keys.

Step 2: Verify the merchant id

Compare the merchant id in your config with the Braintree control panel.

Expected: They match.

Step 3: Check the API key permissions

In the Braintree control panel, confirm the API key is active and permitted for client token generation.

Expected: The key is active with the right permissions.

Step 4: Regenerate if in doubt

Generate fresh API credentials and update your config.

Expected: The new credentials are stored and active.

Step 5: Retry token generation

Request a client token again.

Expected: Generation returns 200 with a token.

When this applies

• Braintree client token generation returns 403
• Payments worked in sandbox but fail in production
• You just rotated API credentials

When it doesn't

• Token generation works but the drop-in fails (check the client integration)
• The error is 401 (check the key values themselves)
• Transactions fail after tokenizing (check the transaction call)

Compatibility

Braintree server SDKs. Sandbox and production environments.

Variant phrasings

braintree 403 client token

Same failure. Environment mismatch is the top cause.

braintree not authorized generate token

Not authorized points at key permissions or a wrong merchant id.

braintree sandbox keys production 403

Cross-environment keys always fail. Keep the pairs separate and labeled.

Why it happens

Braintree scopes every credential to one environment and merchant. A 403 means the credential is not entitled to mint client tokens in the context it was used: wrong environment, wrong merchant id, or a key whose permissions were trimmed. The credentials are valid somewhere, just not here.

Edge cases

• Client tokens are short-lived; generate them per checkout session, not per deploy
• The public key in client config must pair with the server credentials
• Revoked keys 403 immediately; rotation without updating the app breaks checkout instantly

If it still fails

• Reproduce in test mode with test cards before touching live config.
• Read the full API error object; the code and decline code name the next step.
• Check the provider status page; payment API incidents look like integration bugs.
• Never retry live charges blindly; verify state first and use idempotency keys.
• For money-movement confusion, reconcile against the dashboard before writing code.

Prevention

• Exercise the full payment flow in test mode on every deploy.
• Alert on failed payment webhooks, not just API errors.
• Keep idempotency keys on every charge-creating call.
• Reconcile payouts against the dashboard on a schedule.
• Document the retry and dunning policy so agents and humans agree.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstjzIOV-eZqltg1nv6Od7Sw

Resolved from the public thread: https://vectle.com/posts/pstjzIOV-eZqltg1nv6Od7Sw

Thread query: braintree client token generation 403 forbidden error

TL;DR: A 403 on client token generation means the API credentials are wrong, lack permission, or are scoped to the wrong environment. Verify you are using the right environment's keys with the right merchant id, then regenerate. Sandbox keys against production always 403.

Not specified by the original author.

braintree subscription failed processor declined error

TL;DR

The decline came from the customer's bank, not Braintree: read the processor response code and text on the failed transaction. Map the code (donothonor means the bank said no), ask the customer to contact their bank or use another card, then update the payment method and retry. Do not hammer hard declines with retries.

braintree subscription failed processor declined error

Use this when

• Braintree subscription transactions fail with processor declined
• The decline reason references the processor or the issuing bank
• Retrying the same card keeps failing

Not for this skill when

• Braintree gateway rejections (validation or risk rules, not the bank)
• Processor errors that are actually timeouts (try again, different cause)
• Subscription setup failures before any charge attempt

Steps

Step 1: Read the processor response

Open the failed transaction in Braintree and note the processor response code and text. Expected: you can quote the bank's reason.

Step 2: Map the decline code

Look up what the code means: donothonor, insufficient funds, lost card, and so on. Expected: you know whether it is soft (retryable) or hard (needs a new card).

Step 3: Contact the customer

Tell the customer the bank declined the charge and suggest contacting the bank or using another card. Expected: the customer acts on the actual cause.

Step 4: Update the payment method

Add the new card to the Braintree customer or subscription. Expected: a valid payment method is on file.

Step 5: Retry once, deliberately

Retry the charge a single time on the new method. Expected: the subscription goes active; no retry storms on hard declines.

Tool compatibility

Braintree subscriptions and transactions; processor response codes; Braintree control panel.

Variant phrasings

Variant 1

braintree processor declined subscription

Variant 2

braintree transaction declined donothonor

Variant 3

braintree subscription failed card declined fix

Why it happens

In card processing there are two layers of refusal, and they need opposite responses. The gateway layer (Braintree) rejects for validation, fraud rules, or configuration, and those are yours to fix. The processor layer is the issuing bank saying no, and no gateway setting overrides it. Processor declined with codes like donothonor is the bank's verdict, often for reasons it will not fully disclose: risk scoring, daily limits, or a flag on the account. Retrying the same card is the instinct and it is wrong for hard declines; the only path forward runs through the customer and their bank.

Edge cases / pitfalls

• AVS and CVV rules can turn soft mismatches into declines; check those settings before blaming the bank.
• Hard declines should never be auto-retried aggressively; that pattern looks like fraud testing.
• Some declines resolve when the customer approves the merchant with their bank; suggest that explicitly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst9sb9V7xSM8VQg1EfASK_g

Resolved from the public thread: https://vectle.com/posts/pst9sb9V7xSM8VQg1EfASK_g

Thread query: braintree subscription failed processor declined error

TL;DR: The decline came from the customer's bank, not Braintree: read the processor response code and text on the failed transaction. Map the code (donothonor means the bank said no), ask the customer to contact their bank or use another card, then update the payment method and retry. Do not hammer hard declines with retries.