Where is Authorize.net Payment Plugin in v4?

I just upgraded to version 4.1.9 via the upgrade notice in my amember admin, however the authorize.net plug in is not displayed? Please see attached images.

Was this pulled from the upgrade?

Thanks

I missed a step in this list.

You first have to enable the "cc" module (just above the Payment Plugins section) and save the page. Then you will see authorize-cim in the payment plugin list

I'd love to hear how well this working. Any feedback?

Cheers!

Does this version still have the customer enter their cc info on our site rather than the authorize site? I thought I was avoiding all PCI DSS compliance issues by never having any cc info touch my site, but the authorize.net plugin is accepting the cc info on my site.

Thanks for the quick reply, Alexander. Your customer service has always been top notch. Unfortunately, the fact that the number is entered on my site means I have to pay $115 to certify PCI DSS compliance, which I wouldn't have to do if it was entered on authorize.net's site. Of course it would be higher if the info was stored in the database...

I am extremely disappointed to find this out. I was also under the impression that the cc info was taken on the authorize.net site, therefore passing PCI compliance requirements on them.

I have passed PCI compliance scans for my own server for the past year and am tired of the hassle. I specifically came to amember thinking it was a solution, only to find that the new integration with CIM presents the same problem as the solution I am migrating from.

Do the developers not understand that merely collecting the data on a form with your domain in the url requres a quarterly PCI scan and $100 plus fee/year? Forum after forum, I am getting mis-informed by developers trying to sell me extensions and programs that they say I will not be required to be PCI compliant for, then tell me that the CC info is collected on my site and passed securely to (insert major payment gateway here)? I have been fined, passed scans, and audited, and know that if you are collecting the information with your domain in the URL, the site owner is responsible.

Is there any possibility that you will integrate this in the near future?

Page 12 on the document you linked to is where you are guided to choose the SAQ and attestation that best apply.

From my understanding, unless you qualify for SAQ A, you are required to have a quarterly scan to ensure that the server where your website is hosted is PCI compliant.

The second bullet on page 12 states

The key word here being, transmit.

By accepting the data on a site with my domain in the URL, into a form that is served from my server, I am transmitting (secure or not) the CC data to the gateway.

By failing SAQ A, the next applicable level for an ecommerce site is C, which requires a scan.

This is the situation that I am currently in with one of my sites, I have contested the security of passing the information securely with a cURL statement, explaining that the data never actually is collected on my server, it only, "kinda passes through." However their point has been that if the domain name access is compromised, any decent coder could direct that information elsewhere without anyone being the wiser.

The problem I am finding however is that i keep getting advice from developers that say that collecting the information on my site is fine, and not to worry. What they seem to miss is that as the site owner, I am the one who is liable if data is stolen. Ultimately I will be the one left holding the bag as not following the PCI compliance standards.

I want to thank you for your reply and hope I am not being too brash. I am really frustrated about how grey these lines are, and am really curious why more people are not asking these questions.

My understanding of the PCI compliance standards in the first place is for the CC companies to release themselves from liability and put more of the burden onto us merchants. We need to be looking out for each other and making sure we are all clear about what is expected of us, and ultimately what we are liable for.

Thanks for your time, and I would really like to discuss this further.

Did the "User authentication failed due to invalid authentication values." ever get resolved? I am getting this error trying to set this up. I have authorize CIM setup on amember and with authorize.net, but when I click submit it gives me the error. Any steps to resolve?

Thank you, my copy and paste had not worked the first time.

Has there been any update to this?

We're trying to go through the process of being re-accepted by Authorize, and it really is very critical that CC info never ever touches the server if the option is available and you're concerned about liability. I don't have all the details yet, but there is a way to integrate using CIM where the CC info is actually submitted in an iframe to Authorize without the customer leaving the site or data passing through aMember. Developers blow this kind of security off much too easily. I know, because I've been a developer since 1995 on a wide variety of projects. I've seen sites get hacked before and it won't be the last time.

The idea is to avoid the loss of data if/when a hacker injects code into aMember that allows them to monitor/log CC info in those few seconds its posted back to the server and relayed back out through the API. I can tell you from very recent experience that hackers will often gain access to a server, quietly manipulate files, and hangout there for months before you ever know something is wrong. In that time they can be capturing all kinds of information and continue to dig their claws deeper into your website. The hacker I'm dealing with is a pro from the middle-east being paid to attack US-based websites. Despite our best efforts, he got in months ago, held the site ransom just recently, and now we're forced to rebuild the site virtually from scratch.

I can't express this strong enough... If there is an option to collect payment off site, even if it doesn't look like that's how its being done, then there is absolutely no question that type solution is by far the best and should be top priority for aMember.

Keep in mind that PCI compliance protects your payment/merchant company FAR more than it protects you. If you get hacked, even if PCI compliant, at the end of the day you are probably going still hold the majority of the liability for the loss of CC information.

Excellent! Thank you for clearing that up!

I am using authorize.net AIM right now and the billing is going OK the problem I have is it will not cancel the recurring billing. Should I switch to the CIM version and if so will this effect my current customer recurring billing???