Posted: January 11, 2019 at 1:54 pm
So we are almost done migrating a site from EE3 to EE4. In the EE3 site, when people register and click to pay with a credit card, they get sent to Authorize.net’s site. In EE4, it appears when click to pay with a credit card, they stay on our website and the credit card form (that used to be on Authorize.net’s site) appears. Is this right? Is that safe? I can’t actually checkout on our dev EE4 site even with the test mode on but I think it might be because the Relay/Response URLs on authorize.net are set to the main site domain still. I have already entered our Authorize.net IDs in the Event Espresso Payment Settings area under AIM. Am I missing something else or is it supposed to function the way it is functioning? |
|
Your best option would be to use the Authorize.net Accept solution (available as an add-on) because both AIM and SIM have been deprecated by Authorize.net. Accept is also the easier path to PCI compliance compared to AIM. |
|
From what I can tell the only difference between AIM and Accept is Accept uses an iframe to embed an authorize.net form and AIM does not, is that right? If we stick with EE4’s default of AIM, are there any additional things we need to do besides add a SSL cert? Does the website save payment information that was sent using AIM or does all of that info get saved on authorize.net’s site? |
|
Correct, but that’s a HUGE difference in multiple ways.
For PCI compliance? Yes, there’s a lot more to it as you’ll need the highest level of compliance. There’s far too much to list here, it’s not just about an SSL cert but your servers config etc. Using a shared server? If the answer to any of the above is yes…. don’t use AIM, you aren’t compliant.
No the website does not save the details, but not it’s not just about saving the details, it’s also the transmission of details from your site to Auth.net. One of the reasons Accept is available is to provide you with a way to be PCI compliant with the least amount of effort, that and the fact that Auth.net’s other integration methods are now deprecated. |
|
Okay, thank you. The host actually is not on a shared server, using phpmyadmin, any of that….but it sounds like it might be best to be safe and use the add-on anyway. |
|
Yeah, if you have the option to pass off PCI compliance to a 3rd party, I’d recommend doing so as it can be quite the headache/nightmare for you if you get it wrong. Note you actually do still a level of compliance regardless of whichever integration method you choose, the difference here being for our Accept integration you need SAQ-A… which is basically, fill a form in and some simple checks as the ‘hard’ part is done by Auth.net. With AIM you need SAQ-D (which is the highest level) and requires you basically have everything that auth.net has in place, but yourself on your own server (well actually your host but same point). It’s not just SSL but maintenance on the server, who has physical access to the server and so on (it’s fairly involved). |
|
The support post ‘Confused about Authorize.net options’ is closed to new replies.
Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.