ISO 8583 response code: 54

Field 14 carries the expiry as YYMM. A 54 means the issuer compared it against the account and rejected it — either the card is genuinely past its expiry, or the value sent does not match the issuer's record. The second case is worth ruling out, because a YYMM/MMYY transposition produces a 54 for a card that is perfectly valid.

• The card has genuinely expired and been replaced.
• The expiry sent in the wrong order — MMYY instead of the YYMM that field 14 requires.
• A stored credential holding an expiry that was never updated after the cardholder was reissued.
• A month sent as 1 rather than 01, shifting the field and producing a date the issuer does not recognise.

1. Confirm field 14 is YYMM, four digits, zero-padded — December 2027 is 2712, not 1227.
2. Ask the cardholder for the current expiry date. If the card was reissued with the same number and a new date, that alone will fix it.
3. For subscriptions, use an account updater service with your acquirer so reissued cards are refreshed before the charge fails.
4. Check the expiry before sending. A locally expired date needs no network round trip to reject, and refusing it in your own form is a better customer experience than a decline.

• ISO 8583 14Invalid card number (no such number)
• ISO 8583 05Do not honour
• Stripe expired_cardexpired_card

• Card test toolkit
• ISO 8583 message parser

What order does field 14 use?

YYMM — year first. It is the reverse of how expiry dates are printed on the card itself, which is why transposing it is such a common bug. A card expiring in December 2027 is sent as 2712.

Can I get a 54 on a card that has not expired?

Yes, and it usually means the date you sent does not match the issuer's record rather than that the card is past its date. A transposed YYMM, an unpadded month, or a stale stored expiry all produce it. Check your formatting before asking the customer for a new card.