CIM Hosted Payment Form - wish for an enhancement

[marybeihl]

We are a "card not present" shop because we currently use CIM to store frequent customer's payment info and then can easily ring up sales for them without having to ask for the credit card again.

We use the hosted payment form on our PC-based cash register to send the payment info to CIM so that we are totally PCI-compliant and do not store or transmit the cc.

But at the time of creating a customer's payment profile, we do have the credit card handy as the customer does come into our stores.  The cashiers find it frustrating that they often typo cc numbers.  They also dislike that they have to type in the customer address into our system (for shipping info and whatnot) and then again on the hosted payment form.

A request from them was made:  could the hosted payment form be modified to take input from a card reader and populate the appropriate fields (card holder name, card number, expiration date, etc).

Of course, we can't do this since it is auth.net's form but...it really is quite an easy thing to do with java script so we thought we'd ask if that would be functionality that you could add to the form?

I'd even offer to write the javascript for you!

[TJPride]

This has been asked before, and the answer is no. There is no point to having a hosted form at all if you're just going to fill in the values using the regular old methods. You might as well just use regular CIM. CP accounts generally use AIM, which is the same in terms of security requirements, and it sounds like this is really a CP situation. The trick is to have the computer you're using as a register connect directly to Authorize.net, rather than using a web server as an intermediary (if that's what you're doing), and to eliminate any network connections or software other than absolutely necessary stuff. You may be able to pass the security requirements that way, though it's pretty much impossible with a web server.

[marybeihl]

But the nice this about the hosted form is that our code doesn't touch the cc info in any way.  We are looking at using the CIM CreateCustomerPaymentProfile webservice but that requires us to create a form and collect the cc info via our code.  This opens us up for PCI- compliance auditing from Visa.  With the hosted form, we can say we are totally compliant because we are using your web pages which are already PCI-compliant and not have to worry about auditing.  Management really likes that.

We don't use a web server.  We create the html page on the fly adding the customer profile ID to the hidden post variable.   We save the page to the local hard drive and then display this page in a form with a web browser control on it.

I'm surprised to hear you say so flat out, no.  It isn't much work, right?  Just a bit of javascript to parse out the input if it looks like data from a card swipe.  It wouldn't hurt anything else, right?

Especially if you've had other requests for this, it would be nice if you could accomodate....

[TJPride]

I don't work for Authorize.net. I'm sure they'd be more diplomatic about it, but this -is- something they've answered before.

FYI, it doesn't really matter how you're serving the credit card data to Authorize.net, you're still having it pass through your computer. The approach you're using is no different from a security perspective than having an actual coded solution that receives data from the swiper and passes internally to Authorize.net, as opposed to filling in a form using Javascript. You still have to pass the security requirements for a point of sale terminal, which are more or less what I laid out before.

If you have a CP account, you can pass track data rather than parsing it, btw.