Reply
Member
Posts: 4
Registered: ‎05-28-2015
Accepted Solution

Cannot post payments after May 27 security change

Hello, Pioneer Credit Counseling uses Authorize.net with a custom made PHP application on a Centos 5.9 server.  It is currently running PHP 5.3.28.  We are unable to receive payments through our web site since the May 27 security change.  We are incurring increased labor cost and are losing customers.  Our previous developer for the PHP code may no longer be available, but we haven't yet found a new developer.  We were not aware of the Developer blog before 5/28 but we are signed up now and checking this daily.  We were unprepared for this. 

 

Since last Thursday morning we have had a couple of businesses look at this system.  Our IT management company installed the 4 security certificates listed on the Developer blog post on the changes.  After this did not fix the problem, they investigated and said the PHP code would need to be rewritten.  They indicated that IP addresses were hard coded in the PHP code.  A website development company also looked and reported that our PHP code was not compatible with SHA-2. 

 

Is there any temporary measure that could be employed to allow us to connect with old settings while we resolve the issue?  I have some programming experience, though not with PHP.  I have Putty access to the server and ability to search for files and some other very limited Linux knowledge.  I am told our web application only allows payment in 2 different areas.  If anyone has tips on how to start investigating this further myself, or questions please let me know!


Accepted Solutions
Highlighted
Solution
Accepted by topic author PioneerCredit
‎08-21-2015 01:58 AM
Member
Posts: 4
Registered: ‎05-28-2015

Re: Cannot post payments after May 27 security change

Our company is working to set up payment authorization through another payment services provider separate from Authorize.net.  That provider was able to refer us to a developer who was able to fix this problem by installing a certificate from the other payment provider.  Our application is working again now.

View solution in original post


All Replies
Member
Posts: 4
Registered: ‎05-28-2015

Re: Cannot post payments after May 27 security change

I have investigated one of the pages where we allow online payment. The section of code below is responsible for creating the transaction.  It is referencing an included file named AuthorizeNet.php which appears to have been obtained from Authorize.Net.  I am nearly certain we are not using a hard coded IP address, because the AuthorizeNet.php includes AuthorizeNetAIM.php which contains the URLs for testing and production, and I don't see a hard coded IP address in our php.  Can anyone tell me how I can find out if we need to obtain a new version of the Authorize.Net API files?

 

I have removed the API Login ID number and Transaction key number in the next line

 $transaction = new AuthorizeNetAIM('', '');
  $transaction->amount = $_SESSION['PaymentAmount']; // New feature to prevent sneaky people from overriding our rates in the future.
  $transaction->card_num = $_SESSION['CardNumber'];
  $exp_year = substr($_SESSION['ExpirationYear'], -2);
  $exp_month = $_SESSION['ExpirationMonth'];
  $transaction->exp_date = $exp_month.'/'.$exp_year;
  $transaction->card_code = $_SESSION['SecurityCode'];

  $transaction->first_name = $_SESSION['CardholderFirstName'];
  $transaction->last_name = $_SESSION['CardholderLastName'];
  $transaction->address = $_SESSION['CardholderStreetAddress'];
  $transaction->city = $_SESSION['CardholderCity'];
  $transaction->state = $_SESSION['CardholderState'];
  $transaction->zip = $_SESSION['CardholderPostalCode'];
  $transaction->country = 'US';
  $transaction->phone = $_SESSION['HomePhone'];
  //$transaction->invoice_num = $_SESSION['ConsumerCourseID']['CC'];
  //$transaction->invoice_num = $_SESSION['ConsumerCourseID']['CC'];
  //$transaction->cust_id = $_SESSION['ConsumerID'];
  $transaction->description = 'DMP PAYMENT';
  $transaction->customer_ip = $_SERVER['REMOTE_ADDR'];
  $transaction->email = $_SESSION['Email'];
  $transaction->customer_tax_id = '00000'.$_SESSION['SSNLastFour'];
  //$transaction->ship_to_first_name = $_SESSION['FirstName'];
  //$transaction->ship_to_last_name = $_SESSION['LastName'];
  $response = $transaction->authorizeAndCapture();
  // Figure out the response from the processor, set a message, and decide what to do next.

Moderator
Posts: 590
Registered: ‎08-21-2009

Re: Cannot post payments after May 27 security change

If you are using an older version of the Authorize.Net PHP SDK and it just stopped working as of our certificate change, there is a very good chance that all you need is to update the .pem file that is included in the SDK. You can download the this file directly from github and drop it into your exisitng release. Or you can download the entire new SDK bundle.

Member
Posts: 4
Registered: ‎05-28-2015

Re: Cannot post payments after May 27 security change

Thank you for the reply Trevor.  Our IT management service had tried installing the 4 new certificates we found in the link below but this did not solve the problem.  They tried this on 5/28/2015.  From what I can tell, that is what you had suggested, please let me know if I have misunderstood your suggestion.  I don't know how to install those certificates to try it for myself, but I could ask our IT management service to try installing them again.  Do you know of a way I could check if the correct certificates are installed from a SSL command line to our Centos 5.9 server?

 

Authorize.Net Developer Blog: Production Certificate Upgrades begin May 27 2015

http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Production-Certificate-...

 

Highlighted
Solution
Accepted by topic author PioneerCredit
‎08-21-2015 01:58 AM
Member
Posts: 4
Registered: ‎05-28-2015

Re: Cannot post payments after May 27 security change

Our company is working to set up payment authorization through another payment services provider separate from Authorize.net.  That provider was able to refer us to a developer who was able to fix this problem by installing a certificate from the other payment provider.  Our application is working again now.