AIM and SIM have reached End of Life

[ozEworks]

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. 

[phi148]

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

[♥Dan Cole]

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

[♥BrockleyJohn]

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

[phi148]

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. 

[♥Dan Cole]

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

[♥BrockleyJohn]

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

[phi148]

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

[♥ecartz]

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. 

[♥BrockleyJohn]

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.

[phi148]

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);
		      
			} 
      }

 

[ozEworks]

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.

 

 

[anya2001]

Is there any update on this?  Is osCommerce developing a new module?

[♥ecartz]

2 hours ago, anya2001 said:

Is there any update on this?  Is osCommerce developing a new module?

As far as I know, no one associated with osCommerce or Phoenix is working on a new module. 

Note that there is no requirement that a payment module be provided by osCommerce or Phoenix.  Authorize.net or a third party could make a payment module.  Like all modules (including the old Authorize.net modules), it should be a drop-in install without any need to modify core. 

[rule]

Any progress? Is no one really using this gateway anymore? They are huge.

[♥BrockleyJohn]

I am canvassing the support (as opposed to demand) for a phoenix module and have done some preliminary scoping. It is pencilled on this year's list of things to do if I think it's worth it (ie if I'll get paid for them:)

AIM is still only deprecated with no end of life date announced, so no need to panic just yet.

[♥Dan Cole]

John...I use Authorize.net and would be willing to contribute to the effort if you decide to develop a module for whatever service they continue to offer.

Dan

 

[phi148]

I also use this and I am willing to help as well.