Mastercard 4812 (Retired) - Account Number Not on File
- 4812 is retired. It was consolidated into 4808 and survives only as a deprecated alias
- While it ran, it meant the account number didn't exist at the issuer
- Chargeback window was 90 calendar days from settlement, 120 for ATM and Maestro in Europe
- Options were thin. An invalid account number is hard to argue with
4812 is no longer a chargeback reason code. Mastercard consolidated the authorization-related codes into 4808 in its 2016 reason-code consolidation. In the current Mastercard Chargeback Guide, 4812 appears only as a deprecated sender-memo alias for 4808 - a label some systems still transmit, not a code anyone can file under.
Working a dispute today? Use 4808 - Authorization-Related Chargeback, which now covers invalid and closed account numbers.
Seeing 4812 on a current notification? Because it can still ride along as a deprecated alias, this one is genuinely ambiguous: it may be a real 4808 case wearing an old label, or it may be a processor or vendor working from stale material. Don't respond to it as a standalone 4812. Ask your processor for the message reason code on the case, confirm it's 4808, and build your response around the authorization record for the account number as it was actually submitted.
Everything below describes how 4812 worked as a standalone code. It's preserved because old notifications, archived case files, and legacy vendor content still cite it, and the deprecated alias means the number still surfaces in real systems.
What 4812 Covered
A transaction ran against an account number that was never valid, had been closed, or wasn't in the issuer's system at all.
Typical triggers:
- Account number was never valid
- Account closed before the transaction
- Card number doesn't exist in issuer records
- Keyed number with digit errors
- Test card number used in production
Conditions for Valid Chargeback
The issuer had to show three things. The account number wasn't on file. It wasn't valid at transaction time. The transaction got processed to it anyway.
Common Scenarios
| Scenario | Description |
|---|---|
| Closed account | Card cancelled, account terminated |
| Never issued | Number never assigned to cardholder |
| Digit transposition | Keyed entry error |
| Test card | Sandbox card used in production |
Time Frames
| Region | Chargeback Window |
|---|---|
| Standard | 90 calendar days from settlement |
| ATM/Maestro Europe | 120 calendar days |
Representment Options
Options were thin. An invalid account number is hard to argue with.
1. The Account Was Valid at Transaction Time
Evidence required:
- Authorization approval code
- Proof the auth was obtained successfully
- Account active at auth time
2. The Cardholder Used This Account
Evidence required:
- Cardholder correspondence
- Prior transactions on the same account
- Account matched cardholder identity
3. Processing Error on the Acquirer Side
Evidence required:
- Proof the account number was correct
- Evidence the error happened in transmission
- Processor confirmation
Win Rate Expectations
| Scenario | Expected Win Rate |
|---|---|
| Account was valid (auth obtained) | 70-85% |
| Processing error proven | 50-70% |
| Account never valid | Under 10% |
Where This Breaks
Most of these came from keying. Someone typed the number wrong and nothing caught it.
Luhn and BIN checks catch a lot of that before the transaction leaves your terminal. Read the number back to the customer as well. Better still, don't key at all. Dip the chip or tap.
Timing caused the rest. The auth clears, the cardholder closes the account, and your capture lands days later on a dead number. Capture faster and that gap closes.
The dumbest version is a sandbox card in production. Separate your environments and reject test BINs outright.
Related Codes
- 4808 - Authorization-Related (the live code that absorbed 4812)
- 4807 - Warning Bulletin (also retired into 4808)
- 4837 - No Cardholder Authorization