braintree error 91567: payment method nonce already consumed

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