Support

November 6, 2014 at 10:31 pm

I forgot to add that I have been monitoring the moneris_hpp.log, and it seems that some of the time, the failed transactions coincide with an entry like this one:

IPN Validation Errors: Couldn’t resolve host ‘www3.moneris.com’
[11/07/2014 12:17 AM]

Which obviously means what it says; however, I cross-checked those error datestamps against the transactions attempted at those times, and not all of them are broken (but many are), so it’s obviously unable to contact the IPN page properly sometimes, but I’m unsure as to why.

I also added a code snippet I got from another support forum entry to try and improve the logging verbosity in the EE_Moneris_HPP.class.php file, but it hasn’t helped yet:

$this->moneris_hpp_log( $log_entry, TRUE );
if ($this->ipnData['response_code'] < 50) {
return TRUE;
} else {
return FALSE;
}

November 7, 2014 at 12:13 pm

Hi:

No new information in the logs; the issue is that payments go through, so I’m assuming that means that the status code wouldn’t change.

Moneris wasn’t able to tell me anything definitive, but they said these types of errors most often happen when the redirect page is HTTP, not HTTPS. All of ours are HTTPS. They suggested either trying to set up some logging on the redirection page (in our case, the ‘thank you’ page), and/or trying to get their asynchronous URL feature working, which would provide an XML dump of what was posted. I’m not sure where to begin on either suggestion within EE.

I noticed another EE support agent suggesting a simplified transaction page template which fixed some Paypal IPN issues, but the instructions provided in the zip file are nonsensical to me.

The man hours lost to this are piling up.

November 7, 2014 at 8:41 pm

Thanks Lorenzo, I’ve done so and it’s not made a dramatic difference in the results. There are still people whose registrations are being missed (they ‘register’, pay via Moneris, and then have no entry in the db, sometimes have an id that has moved up a couple of numbers from the original, or don’t have their payment status updated and show as incomplete).

November 12, 2014 at 11:26 am

While I test that, I will mention again – the idea that people clicking “back” on any kind of regular basis would likely be because some part of the transaction process was slow to load, perhaps getting to Moneris or getting back from Moneris. However, we have another site on the same server which also uses Moneris as its payment gateway and doesn’t experience any of these problems.

November 12, 2014 at 3:23 pm

Hi Josh:

I’ve had full logging on but just noticed it wasn’t writing properly – odd, because I’ve had the moneris_hpp.log writing fine to the same directory, but I just retried the chmod command on the directory and it started working again. This should help me be able to better diagnose when this issue happens, however, is it just going to accumulate as one huge log file? Or is there a setting to have it roll over? (I could write a cron job if needs be)

November 12, 2014 at 8:33 pm

Another caveat I didn’t mention before – occasionally one of our staff will enter in attendees through the wp-admin section, and there is no payment that takes place (she collects cash/cheques and then enters the payee as an attendee), and some of those registrations have had the same thing happen.