Showing results for 
Search instead for 
Did you mean: 

AIM Moodle integration is now broke as of 8-26

Hello folks,


A broken integration brings me to this forum unfortunatley. Our Moodle site has been operating for about 2 years perfectly but this morning I learned it is not working correctly. This plugin uses an AIM method and nothing has been touched / changed at the site. Our SSL certificate is still good and was issued through godaddy.


Not sure if transaction are working or not, need to wait until the end of day to see how it reconciles. But Basically, learners try to purchase a course and then there is an error, enrolment does not occur.


I am not the only one - other Moodle sites have broke too you can see an active thread of the issue:


I also documented the trouble in a movie here:


So, I am asking, does anyone know of a change that has happened to AIM method? Security or otherwise that would break an older site? I don't know what to fix , because I don't fully know what the problem is yet.


Thanks for any insight / next step ideas.





Accepted Solutions

UPDATE. A fix has been found and tested for 1.9 moodle sites and you can find it in this thread (same as above):

View solution in original post




We've read your report and are taking a closer look.  I'll reply here when there is new information available.



Administrator Administrator

Hey, I don't know what moodle is but I wanted to let you know that I have a custom AIM integration. The response from the AIM server is usually something like this:


3,1,6,The credit card number is invalid.,,P,0,,,6.37,CC,auth_capture,,,,,,,,,,,,,,,,,,,,,,,,,,EDITEDKAJDFKJADF348UJDKFJDF


But yesterday (at least the first time I noticed it), it started adding two lines before the typical response:


Expires: Thu, 01 Jan 1970 00:00:00^M
3,1,6,The credit card number is invalid.,,P,0,,,6.37,CC,auth_capture,,,,,,,,,,,,,,,,,,,,,,,,,,EDITEDKAJDFKJADF348UJDKFJDF


This is the url that I'm posting my variables to:


I signed into my account and it looks like I'm using version 3 of the api.


Because I have a custom integration, I was easily able to loop through each line of the response and through all of the lines away that do not have a lot of commas (I did it that way in case you ever remove the two new lines in the future).


I would expect that adding those two new lines would cause quite a bit of trouble for people, and what does it mean, anyway?

I believe the answer to the problem is this:


some simplistic web programs that interact with aim (like mine, admintably), are not understeading the HTTP headers that are received from correctly. Here is how the http headers can be accurately determined and seperated from the message body (which contains the acutal response from


  • an initial line,
  • zero or more header lines,
  • a blank line (i.e. a CRLF by itself), and
  • an optional message body (e.g. a file, or query data, or query output).

My program, like many others, assumed that the response structure would not change from so they simply ignored the first few lines (which were the http headers that were sent originally) so that the program could get to the body of the http response.


Now that an additional HTTP header was added, the program mistakingly assumes that the additional HTTP header is part of the body of the http response.


Although I haven't verified this, my thinking is that two additional http headers were added to the http response and that is why two lines are added to what your moodle program (and my program) thinks is the beginning of the http response.


The better way to handle the http response from would be to accurately strip off the http header by looking for the first blank line. From there on out would be the http body.

Thanks for the ideas jasonh100 . I can verify my test transactions, they were good from yesterday, so the sending to is fine. It's all about the response back that is off. Think I'll put the settings to test mode and see if I can't learn anything more from the POST data being sent.


@Richard - thanks for looking into this.

We made a change today to the date format for a similar report that may resolve your issue.  Please confirm if this change has corrected the problem.



I tried a new transaction this morning, but it came back with the same error , moodle does not understand what is being sent back.


I paste the transaction here :





**Please DO NOT REPLY to this message. E-mail if you have any questions.


========= SECURITY STATEMENT ==========

It is not recommended that you ship product(s) or otherwise grant services relying solely upon this e-mail receipt.


========= GENERAL INFORMATION =========


Merchant : NC Families United, Inc. (872693) Date/Time : 29-Aug-2012 09:19:35 AM


========= ORDER INFORMATION =========

Invoice : 9051

Description : FDA-CFTM

Amount : 45.00 (USD)

Payment Method : Visa

Type : Authorization and Capture


============== RESULTS ==============

Response : This transaction has been approved.

Authorization Code : 081936

Transaction ID : 46072xxxx

Address Verification : Street Address: Match -- First 5 Digits of Zip: Match



Customer ID : 3

First Name : xxxx

Last Name : xxxxxx

Company :

Address :

City : xxxx

State/Province :

Zip/Postal Code : xxxxx

Country : US

Phone :

Fax :

E-Mail : xxxxxxx



First Name :

Last Name :

Company :

Address :

City :

State/Province :

Zip/Postal Code :

Country :



Tax :

Duty :

Freight :

Tax Exempt :

PO Number : 

UPDATE. A fix has been found and tested for 1.9 moodle sites and you can find it in this thread (same as above):

Pretty old post but still feeling lucky read this discussion, thanks to autohrize community for the nice archive.



Thank you very much for the nice share buddy, it's the best answer that i have ever seen in this forum.