Enrolment

Same here too. Authorize.net is closed for weekend.

Yesterday, I asked someone via online chat at Authorize.net if they had changed anything on their end (security settings, etc.) that could explain the enrollment issue and they flatly said no. Granted the person may/may not know what they've changed or may not even think a change they made would impact enrollments.

I'm not saying it's not happening in other programs, but in the past couple of days I don't see any other online reports of Authorize.net enrollments/subscriptions that have stopped working for things like Wordpress/Buddypress, Joomla, etc.

Granted it happened Friday and maybe other reports will come in on Monday, but I would agree that whatever was changed at Authorize is only affecting Moodle installs because of some specific way in which Moodle is actually trying to process the verified enrollments.

On a slightly off topic note, does anyone have any updates on Authorize.net in 2.3? Before this recent problem appeared, I didn't know it wasn't included in core. I know there was an older plugin someone made available that seemed to allow things to still work, but it's very concerning Authorize.net is not built into core.

I feel for the person for whom this is their busiest weekend as I've only had to void 4-5 transactions so far, but for those that charge for individual courses, automating the payment/enrollment option is obviously a critical function for any LMS they use.

I understand PayPal can be used in Moodle 2+ and it may be the defacto/default form of payment in certain parts of the world and they have pending deals with McDonalds/Discover to expand their mobile presense, but there are a variety of valid reasons one might choose not to use PayPal as their default payment method. 

Todd

I have tried a transaction with max debug on and captured a little more information. I made a captivate movie using BadBoy testing browser and post that in a bit after cleanup...

Notice: Undefined offset: 2 in E:\Inetpub\wwwroot\*******.org\enrol\authorize\authorizenetlib.php on line 360

That is interesting. Authorize.net claims they have not made any change.

I get the following string when debugging the $data variable in authorizenetlib.php

Array

{

[0] = Expires: Thu, 01 Jan 1970 00:00:00

}

I think the authorize.net forum thread nails it: the Moodle plugin isn't processing the response from authorize.net properly. It worked in the past but now there are some extra lines which is confusing the Moodle plugin.

Likely it's the authorize_action() function in authorizenetlib.php, where it grabs the response and does an explode() on a delimiter and processes it.

Would be interesting to see the raw response from authorize.net and figure out how to parse it better.

Called Auth.net and the rep said all was fine on their end and nothing looks odd at all. In and out is fine as far as he can see. They have changed nothing.

_{I changed the AVS settings nope, changed transaction key in authorize.net panel and Moodle still get the error.} 

Called auth.net again and the rep I spoke to said that it appears to be something in the headers on their end and though a rare issue they have been getting calls. We tried a card that would flunk and same error message as a good card. 

He said their engineers are working on it and should be resolved today or tomorrow. Crossing fingers!!!! So it appears to be something they think they can fix which would be nice.

Ok this is interesting. I looked in the payment manager of my moodle and it's listing all the errored transactions as a test.

Several of them and a couple from earlier this month.

Thanks for sharing this fix! Working fine in non-test mode.

Many Thanks!  We incorporated it into our live site and it works perfectly.  Hopefully someone at Moodle will incorporate this into future downloads.

You found and fixed it Jeff - Thank so many times !!!

Our site was tested just now still in live mode and the transaction and enrolment all went smooooth as it should.

And thanks to everybody keeping it alive and going.  

Thanks Jeff!  Your fix seems to be working for us.

Thanks Jeff! That worked like a charm!

Hi Jeff,
well done!

If you're able to play with git, you could post there a patch (hosted e.g. in GitHub) using a brand new branch named as the issue ID - plus a short description, no spaces - with just the commit containing the patched file and, if the Core Developer will positively review your commit, the fix will be integrated into Moodle preserving you as the initial commit author.
Otherwise a simple attached Unified Diff file will be fine and it will help in merging and quickly test your patch proposal too.

Matteo

I'm glad Jeff's fix is working for others.

We tried it last night in our 1.9.9 and we still have the same "unknown error" behavior. One of our team is trying to get help from AuthorizeNet now. I'd welcome any ideas why jeff's fix did not work for us, and what might work for us.

Hi John, yes, I'm having issues with my 1.9 site. The payment goes through, but Moodle doesn't recognize the successful payment and the student doesn't get enrolled. I've spent the last day investigating, but haven't made any progress on discovering the issue.

Glen