I have a web application that needs to take the customer's credit card information once and then be able to apply payments to that credit card at various times later on. Due to PCI compliance issues, I don't want to store the credit card data on our servers.
The CIM solution appears to be idea for this scenario, but the one thing I don't fully understand is why/whether I have to use Authorize.net's hosted form because it does not fit well with look and feel of the application. I would prefer to be able to use my own form and have the browser make an API call directly to Authorize.net containing the relevent data.
Does a browser based API like this exist? I guess it would have to encorporate the token received from the getHostedProfilePageRequest call.
Are there PCI compliance reasons why one would not want to do this?
Solved! Go to Solution.
07-25-2013 10:13 AM
Only the two methods mentioned, Standard API and Hosted Payment form, are supported by Authorize.Net.
Richard
07-25-2013 03:07 PM
Hello dland2000,
CIM offers both standard API and hosted payment form options to integrate with your website. For more control of the user experience, you may use standard API using XML or SOAP. However, this method will increase your PCI scope since the data will be passing through your web server.
Using a hosted payment form helps reduce your PCI scope, but it does offer less control over the user experience.
In either case, your should consult with a qualified QSE to ensure PCI compliance.
Visit http://developer.authorize.net/api/cim/ to review the API documentation.
Richard
07-25-2013 12:49 PM
Richard,
Thanks for the reply. I understand that I can either use the XML/SOAP API in my server side code (which I do not want to do because of PCI implications), or I can use the hosted page solution.
What I'm asking is whether there is a third option, which would be an API that can be used from the browser. It would function somewhat like the server side XML/SOAP API but it would be called using Javascript in the browser. Sorry if that wasn't very clear in my initial post.
This would let me have my own form that keeps with the look and feel of the app instead of using your hosted form and it keeps me from having to transfer sensitive data to my server.
07-25-2013 01:00 PM - edited 07-25-2013 01:02 PM
Only the two methods mentioned, Standard API and Hosted Payment form, are supported by Authorize.Net.
Richard
07-25-2013 03:07 PM
I already thought about that myself. You can't expose your keys, since they would have to hit the client at some point to strap them onto the outbound request.
If you take the incoming request, and strap the authentication onto it, then send it via your server. You've tested senstive info and thats a no no.
DPM allows the direct POST securely, but it doesn't create a customer profile, so making CIM useless. I was in the same boat as you a few months ago.
I'm using hosted CIM, and its still not perfect, but it'll work for the most part.
07-25-2013 08:31 PM
Thanks Richard, that's what I wanted to know.
07-26-2013 09:16 AM
"I already thought about that myself. You can't expose your keys, since they would have to hit the client at some point to strap them onto the outbound request.
If you take the incoming request, and strap the authentication onto it, then send it via your server. You've tested senstive info and thats a no no.
DPM allows the direct POST securely, but it doesn't create a customer profile, so making CIM useless. I was in the same boat as you a few months ago.
I'm using hosted CIM, and its still not perfect, but it'll work for the most part."
Yes, you can't expose your account credentials to the browser, but CIM does support that concept of a request token already via getHostedProfilePageRequest. Couldn't you just leverage that token in an API call from the browser? Basically like a mix of CIM and DPM?
07-26-2013 09:19 AM - edited 07-26-2013 09:25 AM
@dland2000 wrote:
Yes, you can't expose your account credentials to the browser, but CIM does support that concept of a request token already via getHostedProfilePageRequest. Couldn't you just leverage that token in an API call from the browser? Basically like a mix of CIM and DPM?
As far I know, I thought the Token was just used to create a hostedPage, whether that be the AddPayment, editPayment, editShipping, addShipping, hostedForum. I don't think you can use that token for much else.
07-26-2013 02:43 PM
The hosted popup doesn't really look -that- bad. You can fudge and have an additional popup that appears next to it with your logo and a brief message about payment (like how much they're going to be charged immediately) and then disappears when the popup disappears. You will also have a templated page in the background, so they can see your main site faintly around the popup, and it's still your URL. Maybe an iframe version would be more slick, something Authorize.net can think about for the future?
07-29-2013 12:24 PM
I appreciate the hosted form option and think it looks nice enough, but I am getting "change bad, why can't you just..." flack helping people transition from a single page everything there order form where the CIM Customer Profile and not touching the payment information is still desired.
I was thinking the same as @dland2000, that it would be awesome to have a client side lite JavaScript CIM API that leveraged the token and allowed XMLHttpRequests or some kind of light weight REST access to do CIM actions on that specific account with the timeout and without the login credentials like the hosted form allows. That would be sweet.
Short of that they are also interested in an iframe option that persists and shows the updated information after editing or adding payment info.
01-03-2014 04:26 PM