# 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."

```text
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__G1vY1_sq7kG4R9xM1ke5g