## TL;DR

The card token was created from a truncated card number, so the charge fails validation with cc_rejected_bad_filled_card_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.

```text
mercadopago cc_rejected_bad_filled_card_number: tokenized card number truncated
```

## Use this when

- Mercado Pago returns cc_rejected_bad_filled_card_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 bad_filled_card_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/pst_XLaD_dElqih-Fg6eMPuOsg