Notable Updates for Authorize.Net - July 2016


Don’t dismiss Authorize.Net too quickly! If you’ve been in the e-commerce sector as long as we have you’ll undoubtedly have plenty of experience with the 20-year-strong Authorize.Net payment gateway. Authorize.Net has been introducing a lot of changes recently, maybe in response to competition from the likes of Braintree, Stripe, and even PayPal.

A lot of  these changes have been desired for a long time so it’s good to see them finally implemented. Anything that makes the user experience more enjoyable and reduces the business’ PCI scope is very welcome. In case you haven’t seen these updates because you’ve moved on to a different gateway we’ll summarize Authorize.Net’s changes to help you catch up quickly.

Migration to Akamai SureRoute is now voluntary

If you wish to use Akamai SureRoute you’ll need to change it over manually. We recommend doing so, but since Authorize.Net is maintaining both methods an even better solution is implementing a fall-back to the non-Akamai endpoint if the SureRoute endpoint has a connection issue.

Originally announced:  ‎June 2016

Accept PayPal Express through your Merchant account

We’ve long been proponents of adding PayPal to your checkout process to assist with detail entry and this helps with adding it. We also like how this consolidates the information into the Authorize.Net merchant reports.

Originally announced: Oct 2015

“Authorize.Net Accept” suite announced

Accept is a new suite of five modules intended to improve the user experience and help reduce PCI scope. “Accept Customer” was announced along with the suite and Accept.js followed shortly after. What will the next three modules be? Whatever they are we’re pretty positive they’ll be well received.

Originally announced: June 2016

First module “Accept Customer” released

We’ve always been on the fence of promoting the use of CIM or the Hosted CIM forms. CIM always gave us issues when we wanted to integrate it with ARB and AIM for authorizations. The Hosted CIM forms were also an annoying user experience and extremely basic. We really had to evaluate if the client needed to keep Authorize.Net and if reducing PCI scope was worth the user impact. Thankfully this new module finally updates the Hosted CIM forms to something a bit more modern.

Originally announced: June 2016

Second module “Accept.js” released

This module intends to be a drop-in replacement for the DPM (Direct Post Method) integration. Unfortunately, it still maintains the same PCI scope of no less than SAQ A-EP due to its javascript submission method.

Originally announced: June 2016

Use “Solution ID” field to help track your client’s transactions

Logging into client accounts has always a pain. Solution ID gives agencies a way to track transactions that used their software along with some reporting of various totals. We’re looking forward to see how this helps us make troubleshooting more efficient.

Originally announced: Sept 2015

TLS 1.2 2017 deadline no longer early 2017

Authorize.Net has not announced any new plans yet for a new deadline. Keep an eye out for that for existing platforms. New solutions are required to use TLS 1.2 per PCI DSS 3.1.

Originally announced: May 2016

Hosted CIM has been deprecated

Don’t hold out for any improvements because Hosted CIM now says “STATUS: Deprecated / Upgrade to Accept Customer.” We talked a bit on the new Accept Customer module earlier in this article. It looks like “Accept Customer” is specifically the hosted forms portion of “Customer Profiles”.

Originally announced: June 2016

CIM profiles integrated with ARB

Finally! This change was so obvious we wonder why it took so long. There have been a lot of changes to the CIM and ARB API calls so it’s probably best to just check out the ARB feature page and start with a fresh understanding.

Originally announced: Over a period of time between 2015 to 2016

Merchants now get ARB, CIM, AFDS, and QB Sync for free

We suggest implementing them for your customers now that there is no additional cost. Reduce your PCI scope as much as possible. Might as well try to implement any applicable AFDS rules as well.

Originally announced: Dec 2014

Mobile POS and encrypted card reader

Don’t leave money on the table by processing as CNP (Card Not Present) when you could be processing them as CP (Card Present) with a lower rate. The mPOS app is free while the card reader is an additional purchase. CNP accounts are also CP capable accounts.

Originally announced: Sept 2014

Developer docs makeover

We like the new look and it’s nicely organized into the various features with good overviews.

Originally announced: Sept 2015

PCI compliance scope reminder

Remember that only sole usage of Hosted CIM (Accept Customer) by itself is capable of SAQ A. Accept.js is no less than SAQ A-EP and any other direct integration with Authorize.Net will most likely be the the more strict SAQ D. There are other potential options of utilizing an Authorize.Net merchant account but in a manner that keeps your scope at SAQ A.

Always check the terms of each provider and see what makes the most sense for your business. Also, keep in mind chargeback fees, others experiences with locked funds, customer service stories, and if your business model will experience any issues.

________________________ Endertech is a Los Angeles Web Developer able to provide solutions for your Ecommerce Design and Development needs. Contact us for your free consultation to reduce your PCI scope.