reason on File dispute. The reason drives how the card network handles the case, so picking the closest match matters more than picking quickly.
Two fields are derived from it and returned on the dispute, so you never send them:
The signature requirement follows the category: every fraud and consumer reason needs one, no authorization or processing error reason does. Read
requiresCardholderSignature off the response rather than encoding that rule in your client.
Fraud
The cardholder did not authorise the charge. All require a signature.
Reach for
FRAUD_OTHER_CARD_PRESENT when you know the transaction was fraudulent and the card was used in person, but not how it was compromised. Use FRAUD_OTHER_CARD_ABSENT for the equivalent case online - it is where a confirmed fraud alert of type ACCOUNT_NUMBER_MISUSE lands when the cardholder still holds the card.
The two FRAUD_EMV_LIABILITY_SHIFT_* reasons carry a condition beyond the kind of fraud: they apply only where the merchant’s terminal lacked the chip or PIN capability that would have prevented the transaction, which is what shifts liability to the merchant. Where the terminal was fully capable, the same fraud is filed as FRAUD_OTHER_CARD_PRESENT instead.
Authorization
The merchant took the charge without valid authorization. No signature required.AUTHORIZATION_NO_AUTH_LATE_PRESENTMENT covers both situations under one reason, so use it whether the authorization was missing entirely or the merchant simply settled too late.
Processing error
The charge reached the cardholder in the wrong shape. No signature required.Consumer
The charge was authorised but the merchant did not hold up their end. All require a signature.CONSUMER_CREDIT_NOT_PROCESSED and CONSUMER_CANCELLED_MERCHANDISE are the pair most often mixed up. Use the first when the merchant agreed to refund and never did. Use the second when the cardholder cancelled or returned per the merchant’s policy and no refund followed.