mercadopago cc_rejected_bad_filled_card_number: tokenized card number truncated

TL;DR

The card token was created from a truncated card number, so the charge fails validation with ccrejectedbadfilledcard_number. Ensure the full card number reaches the token creation call: validate the PAN length client-side, fix any input masking that clips digits, then create a new token and recharge. Never reuse the token made from the truncated number.

mercadopago cc_rejected_bad_filled_card_number: tokenized card number truncated

Use this when

• Mercado Pago returns ccrejectedbadfilledcard_number on a tokenized payment
• Your card form applies input masks
• Tokens work for some cards but fail for longer PANs

Not for this skill when

• The customer genuinely mistyped the card number
• The card is expired or the issuer declines
• You are debugging the token creation API itself

Steps

1. Inspect the card input flow for masking, formatting, or maxlength logic that could clip digits. Expected: You find where the number is shortened.

2. Add client-side validation that the PAN length matches the card brand's expected lengths before tokenizing. Expected: Truncated numbers never reach token creation.

3. Create a new card token with the complete PAN. Expected: A fresh token carries the full number.

4. Resubmit the payment with the new token. Expected: The badfilledcard_number rejection is gone.

5. Log token creation failures with the PAN length (never the PAN) to catch regressions. Expected: Future truncation is visible in logs.

Tool compatibility

Mercado Pago card token (cardtoken) creation and payments API; validation is server-side on the token's PAN.

Variant phrasings

mercadopago bad filled card number token

Short form tying the error to tokenization.

mercadopago card number truncated tokenization

Names the truncation cause.

mercadopago token invalid pan length

The validation angle.

Why it happens

Mercado Pago validates the PAN embedded in the card token at charge time, including brand-specific length checks. When a front-end mask, a maxlength attribute, or a formatting routine clips even one digit, the token is minted over a short number and every charge with it fails validation. The error name says it plainly: the card number as filled is bad. Because the defect is baked into the token, no retry with the same token can succeed; only a new token from the full PAN fixes it.

Edge cases / pitfalls

• Amex PANs are 15 digits and Diners 14: length validation must be brand-aware, not a fixed 16.
• Copy-paste with spaces can also break tokenization: strip whitespace before creating the token.
• Test with the longest PAN your form accepts, not just a standard 16-digit test card.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstXLaDdElqih-Fg6eMPuOsg