We are trying to refund money our client, but can't do it, we get the following error:
[E00027] The credit card has expired.The credit card has expired.
BUT the cc is not expired, the expiration date is 05/2014. We tried to update the payment profile several times, but result is the same. Why? And should we do?
E00027 can mean a number of different things, not just an expired credit card. From Mimi's post:
To find the cause of the transaction failure, you need to search the XML response for an element named directResponse, validationDirectResponse, or validationDirectResponseList. The exact name of the element will vary depending on which CIM function was used. The element will include an AIM response string, and the Response Reason Code for the transaction will be in the third position of that string. You can then use the Resposne Reason Code Tool at http://developer.authorize.net/tools/responsereasoncode/ to find the root cause of the error.
You should do a var dump of the response and paste it here. Use print_r() if using PHP.
Thanks! I looked at the response reason code:
<directResponse>3,1,8,The credit card has expired.,,P,4272040713 ...
So it is
Response Reason Code: 8
Response Reason Text: The credit card has expired.
It is strange, the cc is 100% active, it can not be expired.
Well then, maybe the expiration date isn't being passed properly? Try printing it out on the line before you assign it, then if that doesn't help, look through your SDK and find the part where it actually passes the data to Authorize.net, then print that out and see what the expiration date value is.
Well, that's the correct format to use. Are you sure that it's not a case where the expiration date is after the current date, so nominally ok, but the card itself has expired and the person just gave you an incorrect value for expiratiion date?
In my experience, you can't ever refund a transaction after the time the card that was used for the transaction expires, EVEN IF THE CARD IS LATER UPDATED with a new, correct, expiration date.
For example, if a transaction occurs on April 1st for a card that expires in April (i.e. on April 30th), then that transaction will never be refundable after April 30th - even though the transaction meets all other documented criteria for a refund.
I'd love to be proven wrong, but I believe I've tried every permutation on this. I believe this to be a bug in the Authorize.Net implementation.