nuvei GV_InvalidCardNumber: card tokenized with the wrong safecharge key

TL;DR

Nuvei card tokens are bound to the SafeCharge key used at tokenization: a token created with the wrong key decrypts to garbage and the charge fails with GV_InvalidCardNumber. Re-tokenize the card with the correct key for the environment and resubmit the payment. Keep test and live keys strictly separated so tokens and keys always match.

nuvei GV_InvalidCardNumber: card tokenized with the wrong safecharge key

Use this when

• Nuvei returns GV_InvalidCardNumber on a card that looks valid
• You recently rotated or swapped SafeCharge keys
• Tokens work in one environment but not another

Not for this skill when

• The card number is genuinely mistyped by the customer
• The error comes from 3D Secure rather than tokenization
• You are debugging a different Nuvei gateway error

Steps

1. Confirm which SafeCharge key tokenized the card versus which key the charge request uses. Expected: You find the key mismatch.

2. Re-run the card through tokenization with the correct key for the environment. Expected: You hold a fresh token bound to the right key.

3. Resubmit the payment with the new token. Expected: GV_InvalidCardNumber is gone.

4. Separate test and live keys in config so one environment can never tokenize for the other. Expected: Tokens and keys always match by environment.

5. Invalidate or discard tokens created with the wrong key. Expected: No stale token can be reused.

Tool compatibility

Nuvei (SafeCharge) card tokenization and payments API; key binding is enforced server-side.

Variant phrasings

nuvei invalid card number tokenization key

Names the key cause directly.

safecharge token wrong key

The legacy brand name variant.

nuvei GV_InvalidCardNumber fix

The error-code-first search phrasing.

Why it happens

Tokenization encrypts the PAN against a specific merchant key so the token is only usable within that key's context. When the front end tokenizes with one key and the back end charges with another, decryption yields invalid card data and Nuvei reports GV_InvalidCardNumber. The card itself is fine; the token/key pair is inconsistent. Key swaps during sandbox-to-live migration are the classic trigger.

Edge cases / pitfalls

• Tokens are single-key: never share a token across merchants or environments.
• If your tokenization happens in a mobile SDK, the SDK's configured key must match the server's charge key.
• Log the key identifier (never the key) with each tokenization to make mismatches visible.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstwEupVnUy7HENQ-j0_lpJQ