Jump to content
ozEworks

AIM and SIM have reached End of Life

Recommended Posts

Authorize.net have announced AIM and SIM have reached end of life. They will no longer be supported but you will be able to keep using them..

Specifically their APIs will remain available but not be upgraded. If any PCI compliance changes occur in the future (simple for example you had to collect Card Type as part of the transaction) these APIs will not meet them and you therefore would be not compliant if you continued to used them.

Read full notice here https://support.authorize.net/s/article/Recurring-Billing-Flag-Rebill-Feature-End-of-Life-Overview

There is new API available. See https://developer.authorize.net/api/  and osCOmmerce will need to work to provide a module to use with MS 2.2/2.3. 

So bottom line there is no date associated with this.  Your payment modules will continue to work.  If/when an osCommerce Add On is released using the new API you should upgrade to it. 


Kym

Projects Director @ ozEworks.com

Share this post


Link to post
Share on other sites
On 2/19/2020 at 10:59 PM, phi148 said:

Really need this to be updated!  Anybody working this by chance?

Bill, maybe it would be worthwhile asking someone like @BrockleyJohn (who seems to know his way around the payment modules) for a quote on updating the authorize.net module.  I'm sure there are others interested in getting it updated to and perhaps we can crowd fund it to make it happen. 

Dan

Share this post


Link to post
Share on other sites

@phi148 which of the 3 existing modules are you using currently? Why is it urgent to have it updated?


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (Phoenix).

here: on the official osc download page

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites
23 minutes ago, BrockleyJohn said:

@phi148 which of the 3 existing modules are you using currently? Why is it urgent to have it updated?

Hey all. I’m currently using AIM. However the “rebill” function is going away and AIM is also end of life. 
 

Having to call customers to get their payment info over and over will really become a pain and I was hoping to avoid that. 

Share this post


Link to post
Share on other sites

John here is the actual notice that I received...using AIM as well.

AIM/SIM APIs and Simple Checkout Officially Deprecated
Our legacy Advanced Integration Method (AIM) and Server Integration Method (SIM) APIs, as well as our Simple Checkout option, are officially deprecated, meaning we will no longer provide any updates to these APIs. If your website or payment solution uses one of these methods, this means the following:

    You can continue to process transactions via the APIs and Simple Checkout
    Your use of the APIs and Simple Checkout is “as is,” meaning you will not receive any new updates, including new features, payment network mandate updates, etc.
    Because these methods will no longer be updated, you could face penalties and fees associated with transactions that do not meet mandate/compliance requirements
    Your transaction processing functionality could deteriorate over time

If you are using the AIM/SIM APIs or Simple Checkout, we highly encourage you to upgrade your website or payment solution to use the current Authorize.Net API. This will allow you to stay up to date on new releases, network mandates, and more. Please contact your web developer or payment solution provider for further assistance or to find out whether you are currently using AIM, SIM, or Simple Checkout.

For me I'm not sure I'd call it urgent but it would be nice to get out in front of the bus.  I don't really want to logon some morning only to find that my main payment option is now failing.

Dan

Share this post


Link to post
Share on other sites
7 minutes ago, phi148 said:

Hey all. I’m currently using AIM. However the “rebill” function is going away and AIM is also end of life. 
 

Having to call customers to get their payment info over and over will really become a pain and I was hoping to avoid that. 

The way I read it  the recurring billing function is withdrawn - replacing your api won't help. You have to do it in their customer manager:

Quote
  • Removing Rebill Functionality
    • Rebill allows you to create a new transaction from an existing transaction. We will be removing the rebill functionality from the Merchant Interface. Moving forward, you must create a new transaction if you need to re-bill a customer. We suggest using Authorize.Net’s Customer Information Manager to quickly and easily re-bill your customers

unless you know differently of course


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (Phoenix).

here: on the official osc download page

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites
20 minutes ago, BrockleyJohn said:

The way I read it  the recurring billing function is withdrawn - replacing your api won't help. You have to do it in their customer manager:

unless you know differently of course

I need to find out for sure.  You may be right.  Assuming you are correct, then it looks like I need to implement Authorize.net "CIM".  Which doesn't exist either right now :(

Share this post


Link to post
Share on other sites
33 minutes ago, phi148 said:

it looks like I need to implement Authorize.net "CIM". 

I read that as "Go to our website and use the tool there."  Not use an API at all.  So you shouldn't have to call your customers, but you will have to manually hit the rebill button somewhere that Authorize.net has it. 


Always back up before making changes.

Share this post


Link to post
Share on other sites
1 hour ago, phi148 said:

I need to find out for sure.  You may be right.  Assuming you are correct, then it looks like I need to implement Authorize.net "CIM".  Which doesn't exist either right now :(

You might be right about it being supported - if the existing AIM module has a 'rebill' option then maybe that's what's being withdrawn. There's a set of APIs covering Payment Transactions, Customer Profiles, Rebilling and eChecks. Whether these are different APIs or different aspects of the same one remains to be seen. First impression is there's a lot of groundwork to do.


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (Phoenix).

here: on the official osc download page

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

I fixed it by adding this code to create a customer profile which now lets me save the customers information so I can rebill them easily.  I just added this as a last minute feature after a successful credit card transaction.  Seems to work just fine for me.  I also have it send me an email if it fails for some reason.  That part has not been tested yet since it seems to be working and not executing that code.

	  if ($error == false) {

          $g_loginname = substr(MODULE_PAYMENT_AUTHORIZENET_CC_AIM_LOGIN_ID, 0, 20);
          $g_transactionkey = substr(MODULE_PAYMENT_AUTHORIZENET_CC_AIM_TRANSACTION_KEY, 0, 16);
		  $posturl = "https://api.authorize.net/xml/v1/request.api";

          $content =
			"<?xml version=\"1.0\" encoding=\"utf-8\"?>" .
			"<createCustomerProfileFromTransactionRequest xmlns=\"AnetApi/xml/v1/schema/AnetApiSchema.xsd\">" . 
			"<merchantAuthentication>" .
				"<name>" . $g_loginname . "</name>".
				"<transactionKey>" . $g_transactionkey . "</transactionKey>" .
			"</merchantAuthentication>" . 
			"<transId>" . $response['x_trans_id'] . "</transId>" .
			"</createCustomerProfileFromTransactionRequest>";
			
		    $ch = curl_init();
			curl_setopt($ch, CURLOPT_URL, $posturl);
			curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
			curl_setopt($ch, CURLOPT_HTTPHEADER, Array("Content-Type: text/xml"));
			curl_setopt($ch, CURLOPT_HEADER, false); 
			curl_setopt($ch, CURLOPT_POSTFIELDS, $content);
			curl_setopt($ch, CURLOPT_POST, true);
			curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
			$response_cim = curl_exec($ch);

			curl_close($ch);
			$parsedresponse = @simplexml_load_string($response_cim, "SimpleXMLElement", LIBXML_NOWARNING); 	
			
			if ($parsedresponse->messages->resultCode == "Error") {
	    
		        $to_name = STORE_OWNER;
		        $to_email_address = STORE_OWNER_EMAIL_ADDRESS;
		        $email_subject = '!!! Customer Information Manager Alert !!!';
		        $email_text = '<span style="color:red;">Customers information was not stored in authorize.net</span>';
		        $from_email_name = 'Authorize.net ALERT Notification';
		        $from_email_address = STORE_OWNER_EMAIL_ADDRESS;
		        tep_mail($to_name, $to_email_address, $email_subject, $email_text, $from_email_name, $from_email_address);
		      
			} 
      }

 

Share this post


Link to post
Share on other sites

The bottom lins is Authroize.net wants people to move to their new API and I believe the core of that relates to recurring billing and customer records etc. to be PCI compliant both ends (site and authorize.net). 

They are not going to let you use methods that violate PCI on their end. If you do recurring billing and/or use CIM, you will probably end up with a problem. 

So at some stage the team need to develop a new Authorize.net module based on the new API.

 

 


Kym

Projects Director @ ozEworks.com

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×