Integration and Testing

[DougE]

I would like the follwing in order of priority:

1. no PCI issues, all data stored on Authorize.net servers
2. customization of the payment pages look and feel
3. customers to stay on my site (url and design)

Here is my take:

AIM can do 2 and 3, but not 1. It takes CC data and requires much stricter PCI standards.

SIM can do 1 and 2, but takes you away from your URL

CIM can do 1, 2 and 3

Not sure about DPM.  

I am using ExpressionEngine and CartThrob if that matters...

[TJPride Expert]

If you want people to stay on your site, I think that eliminates SIM. You're then left with AIM and CIM and maybe DPM. All of those collect credit card data on your site, of course, so you then run into PCI - however, none actually store credit card info on your site, so the impact of PCI is pretty much limited to password security and who has access to the hosting. Things which you should be handling anyway.

If you're just processing single charges, I would recommend AIM. If you're processing subscriptions, CIM. As far as PCI goes, certainly look over the rules, but don't go nuts worrying about it unless your client requires formal PCI certification or something. Nobody's going to steal credit cards off your site unless they get into the hosting, and if they get into the hosting, no amount of security is going to save you vs a good hacker.

[larrykluger]

@TJPride, your info on DPM is out of date.

DPM or CIM are the ways to go since it gives you all three of your requirements.

It is NOT true that DBM collects credit card data on your site. What happens is that your site provides the "please enter your credit card number" page to the customer's browser. BUT, the page's post url is to Auth.net servers. This means that the card data is never sent to your site, not even for an instant.

Picture of the data flow from the DPM docs

AIM, on the other hand, sends the card data back to your server. Your server then "turns around" and sends the card data onward to Auth.net. Essentially, your server acts as a proxy to the Auth.net servers. Even if you never store the card data in a database, the card data is still present on your server. This means, according to current PCI, that your server is in the PCI envelope.

(It used to be that if your server merely transited the data--using AIM or equivalents from other gateways--that your server was not covered  by PCI. But that is NO LONGER the case! PCI folks are not dumb, they realize that if your system is compromised, the card data could be intercepted.) 

There are still lots of people laboring under the impression that if they use AIM, their server is not covered by PCI. They are all wrong.

An alternative is to use CIM--but only if you use the new CIM option of "Hosted CIM" See page 8 of the doc

Use CIM if you want to store the customer's credit card so they don't have to re-enter it the next time they want to purchase something. I use CIM for re-billing my customers monthly. -- I can't use ARB since the billed amounts vary.

[TJPride Expert]

Ok, I stand corrected on DPM. I haven't actually used it myself, my experience so far has been with AIM, ARB, and CIM. But I should point out that since the form is on your site, it's still easy for anyone who gains access to your hosting to just change the post URL and insert an intermediary, which essentially scoops out the credit card info and then passes the post data on to Authorize.net. You are therefore no safer with DPM than you are with AIM or CIM, it again boils down to password and access security. Though I suppose the -illusion- of extra security might be appealing to some people.

[DougE]

Thanks for the replies. Very helpful.

[jamesm113]

Is CIM an alternative to DPM/AIM/SIM?  Or do you use CIM in combination with AIM/DPM/SIM?

Thanks

[TJPride Expert]

CIM is the easiest way (in my opinion) to implement ongoing subscriptions or multiple charges without redirecting to a page on Authorize.net. ARB and SIM would be the alternatives to it. AIM and DPM are more for one-time charges, with AIM again being the option that lets you keep everything on your own site.

The short answer is that if you need CIM, you're not going to need anything else for the same transaction. CIM can handle both initial payment and ongoing payments, unlike ARB, which can do ongoing but requires you to use AIM for the first payment.

[jamesm113]

Our customers will be frequent buyers, so we want to have their CC info stored so they can easily make purchases again.  We are also not ready for the risk of using AIM yet.  

So is CIM our best bet?  We were considering DPM, but I don't think that allows you store CC info, is that correct?

Thanks

[larrykluger]

@jamesm113 -- you are correct. The only api that enables you to store the customer's credit card number (on Auth.net) is cim.

When you implement it, be sure to use the "hosted cim" option for collecting the card-holder's details.

Note that your sw won't have direct access to the card number, rather, you store a key that you use to ask cim to make another charge transaction against the stored card.

CIM works great, I use it in production.

[jamesm113]

Thanks! :)