|
ndaniel
|
August 30, 2013 at 11:07 am
It appears that since upgrade to 3.1.34, there have been some issues. Because registrations were for future events (at that time) we didn’t know until recently.
Issue 1) An occurrence of a duplicate billing for one event. It hit Auth.net twice, but only one payment is in EE.
Issue 2) Quite a few issues of payment processing in Auth.net but showing as “declined” in EE. Users say that on the site it showed successful payment and they also had the emails showing that they got confirmation and their ticket. Per configuration, they only get this if the payment is successful.
Not sure what steps to take – both seem to be sporadic issues.
|
|
Josh
|
August 30, 2013 at 3:59 pm
Hi Bill,
Can you check the response logs from Authorize.net that get logged in /wp-content/uploads/espresso/logs and compare the transactions there to the one that got doubled and the quite a few that were marked as declined? This information may help narrow down the issue.
|
|
ndaniel
|
August 31, 2013 at 12:56 pm
Hi Josh,
On Issue #1, I see in our system that the transactions are happening a time apart.
Sometimes a few minutes, sometimes a long while.
There are quite a few now that I review this.
The issue must be resubmission due to page navigation (back button) because the browser session id is identical in each case of duplicate submission.
Do you have any suggestions on where & how I can apply an unset on the payment variables after registration payment is submitted? I need a workaround on this asap.
Cheers,
Bill
|
|
ndaniel
|
August 31, 2013 at 2:16 pm
Hi Josh,
On issue #2, it appears to be a race condition. Again a duplicate session id but the submits happened basically at the same time. Auth.net approves the first, and rejects the 2nd because it is seen as a duplicate submission. EE is getting both, but the registration id is the same the the status is getting updated to the last notification received from Auth.net.
This is resulting in the payment registration showing as declined when in fact it was approved. this causes customer frustration and confusion all around.
If dup submissions can’t be blocked in EE, then I suggest that a check be put in that if the registration payment status is not = default then a constraint be applied so a “success” status on payment via API can’t be changed to “failed”.
Cheers,
Bill
|
|
Sidney Harrell
|
September 2, 2013 at 5:27 pm
Hi Ndaniel,
I did some research and testing of this problem, and I think I may have found a solution for you. If you open up gateways/aim/aim_ipn.php and go to line 47 (you can copy the entire gateways/aim folder to uploads/espresso/gateways/aim in order to preserve your changes from an update), and change it to insert the following:
$transaction->invoice_num = $_POST['invoice_num'];
$transaction->duplicate_window = 120;
the duplicate_window field then being present will mean that when authnet sends a response code 11 (duplicate transaction), it will also send in the authorization_code field, the authorization_code of the original transaction. Therefore, go down to what should then be line 87:
if ($response->approved) {
and change it to:
if (!empty($response->authorization_code)) {
I’m not sure why you are getting duplicated transactions, but the above should ensure that the response recorded in EE reflects the response of the original transaction. If you are getting duplicated transactions that are more than 2 minutes apart, you can change the number of seconds in that line:
$transaction->duplicate_window = 120;
anywhere up to 28800 (8 hours)
|
|
ndaniel
|
September 5, 2013 at 4:55 pm
Sidney – thanks for the guidance.
I will implement this and let you know if there are any other issues.
|
|
Seth Shoultes
|
October 2, 2013 at 11:48 am
Bill,
Did Sidney’s fix work for you?
|
