Expiration date month is being incremented by one. Causing transaction failures for cards that are not Amex (not sure why)!

Problem is in line 501 of includes/authorizenet.inc :
$value = mktime(0, 0, 0, $value['month'] + 1, 1, $value['year']);

Should be:
$value = mktime(0, 0, 0, $value['month'], 1, $value['year']);

Patch included

CommentFileSizeAuthor
authorizenet-expirationdate.patch970 bytesemosbaugh

Comments

allie micka’s picture

allie micka
she/her
commented

Hi emosbaugh,

Have you tried the version that's in Git? I had committed a change like this for #1193328: Problem with Credit Union cards? (And thought I followed up there, but clearly I hadn't)

emosbaugh’s picture

emosbaugh commented

No, I missed that. Is there some reason you are incrementing the month? Also, if the time is one month ahead, I don't believe decrementing the timestamp by one will have the same effect.

EvanDonovan’s picture

EvanDonovan commented

I would agree with emosbaugh on this one. The timestamp is a Unix timestamp, I presume, so subtracting 1 from it is only 1 second, not one month.

I may have a chance to test this patch shortly. About to try Pay + Donate on a client site. Definitely don't want to go live until the transactions work :)

EvanDonovan’s picture

EvanDonovan commented

Actually, I think I'll just use Ubercart Donation Products, since I'm already using Ubercart on the site's store. Sorry.

Lestorx’s picture

Lestorx commented

I had the same issue and applied the change and it worked. Thank you so much!

davidneedham’s picture

davidneedham
he/him
commented

Original fix seems to fix this for me too. Can anyone address the concern in #2?

Is there some reason you are incrementing the month? Also, if the time is one month ahead, I don't believe decrementing the timestamp by one will have the same effect.

allie micka’s picture

allie micka
she/her
commented
Priority: Critical » Normal

A credit card is valid during its expiration month. As of today, a credit card expires in 3/2013 is still valid, and will continue to be valid until 3/31/2013 23:59:59. ( or 4/1/2013 - 1 second).

So the date is likely a red herring for these transaction failures, but I did commit a separate fix for a different issue (comment 1) that may do the trick.

It would help if y'all could post symptoms and behaviors, e.g. error messages returned by Authorize.Net; then perhaps we can get to the bottom of things.

davidneedham’s picture

davidneedham
he/him
commented

I'm using webform_pay. When I had the error about the expiration date, the webform side of things would complete: the user would see the confirmation page and people would be emailed. But unfortunately above the confirmation message, Authorize.net sent back a message that said the expiration date was invalid. This stinks because the user was already emailed, confirming their donation.

I removed the +1 as suggested in the original patch and payments seem to go through just fine now. I haven't yet tried the fix present in the latest dev release.

This may be a different issue, but stems from a similar vein: if I enter an incorrect but valid date in the future, webform will complete (confirmation page + emails sent out) but Authorize.net fails.