Thread

A client runs a small “real world” shop.

He currently processes credit cards payments in his shop using a “physical” terminal.

Now he wants to sell things on his website.

But rather than processing credit card payments on his website using an online payment gateway (like Google Checkout or RBS WorldPay or SagePay or HSBC merchant services or even PayPal), he wants to receive the credit card numbers directly (I suppose by email or by logging into a secure web-page), and then enter them by hand into his existing “physical” terminal in his real-world shop.

He says this will be cheaper for him because he won’t have to pay a subscription to an online payment gateway on top of his existing subscription to his “physical” credit-card terminal.

He assures me that “many websites large and small” use this method to process credit card payments, including (apparently) Ikea.com.

I find this very surprising. I’ve never heard of anyone seriously suggesting this as a good way of handling credit card payments from a website.

I can think of a long list of disadvantages, including:

- Extra time taken to manually type in the numbers.

- Possibility of making a mistake when manually typing in the numbers.

- Long delay between customer placing the order (e.g. on Friday night) and the shopkeeper entering the card details (e.g. on Monday morning).

- If the card does not authorise (perhaps a wrong card number), the customer gets no instant feedback on the website. He has to wait until the shopkeeper has entered the number manually, perhaps hours or days later. And then the shopkeeper has to try to contact the customer to get the correct card details.

- Security: transmitting and storing customers’ credit card details by email seems to me a bad idea. Storing them on a secure website would be better, but still vulnerable to simple things like leaving his computer logged on with the “secure” list of card numbers on screen.

But maybe I’m missing something. Is this really a common way of handling credit card payments on websites? Does anyone have experience of doing it this way?

Does anyone know if Ikea really does it this way?

Or should I tell my client to think again?

There are companies that do it this way, but the companies I know handle large transactions (>5000 up to unlimited) and want/need to verify by hand. All others use gateways.

Sidenote, I live europe and creditcards are far less common in europe the in for instance America. So things might differ.

As to storing creditcards, you should never ever do that. If you don’t have them, you can’t lose them.

The responsible thing to do is inform the client that you have concerns about the method, admit it’s not your area of expertise, and seek professional council on the subject (asking on a community forum doesn’t count).

And then recommend paypal or something similar…

Thanks for the advice guys.

As an aside: I did a little research on this and found that some pre-built systems (like Zen Cart) allow you to do it this way, and deal with the security issue by splitting the credit card number in two. Half of the number is sent by email. The other half is stored on the website. Each half is pretty much useless on its own.

My company specializes in e-comm and let me tell you that PCI compliance is a nasty thing if you end up with any compromised CCs up to $500,000 fine PER card.

Now, I HIGHLY recommend using an payment gateway, I’m sorry, but cheaper don’t mean shit if you can get your ass fined off, lose your business, your business license AND open yourself up to civil lawsuits.

And if he asks if he can store the CVV… RUN, don’t walk away.  That’s opening a can of worms that could potentially put *you* in jeopardy.

I. PCI Compliance Overview
PCI DSS Compliance is an industry-mandated security standard that applies to all businesses that handle, process or store credit cards. There are 12 core requirements and roughly 250 controls, but as an oversimplification it boils down to three things: 1) all merchants, regardless if credit card data is stored, must achieve and maintain compliance at all times (all deadlines have passed); 2) merchants cannot store certain credit card information including CVV2, CVC2 and CID codes (three or four-digit numbers), track data from the magnetic strip or PIN data; 3) if permitted credit card information such as name, credit card number and expiration date is stored, certain security standards are required. A number of recent high profile breaches have been raising awareness and risks associated with PCI Compliance.

http://www.braintreepaymentsolutions.com/blog/merchants-are-prohibited-from-storing-cvv2-csc-per-pci-standards/

http://www.braintreepaymentsolutions.com/pdf/PCI-Compliance.pdf

In the past 4 months I’ve gotten a crash course in e-comm, and let me tell you, you really have to be on your game.

Thanks, brianw1975, for that info. I should have specified that my client is UK-based (as am I). I guess that although the details as far as fines and civil lawsuits may be different here compared to US, as I understand it the PCI DSS rules themselves are supposed to be globally applied by the payment providers.

I understand that you’re not allowed to store CVV codes. Out of interest, how do you interpret “store” here? Say a system “stores” the code over the weekend when, for example, a customer provides the card details on Friday night. Would that kind of “storing” be considered legitimate so long as the code is deleted as soon as it has been inputted manually on Monday morning?

You can check out this for what may be allowed, basically store for critical business function and not for convenience:
(EDIT: Apparently this link only works while you have a valid session through the FAQ site below)
http://selfservice.talisma.com/display/2n/kb/article.aspx?aid=9575

This was taken from the FAQ’s at:
https://www.pcisecuritystandards.org

Maybe I’m just a paranoid American but I second brianw1975. I would dig into the PCI for your answers, but like you said with being UK-based, you may not have as much pressure.

Thanks, brianw1975, for that info. I should have specified that my client is UK-based (as am I). I guess that although the details as far as fines and civil lawsuits may be different here compared to US, as I understand it the PCI DSS rules themselves are supposed to be globally applied by the payment providers.

I understand that you’re not allowed to store CVV codes. Out of interest, how do you interpret “store” here? Say a system “stores” the code over the weekend when, for example, a customer provides the card details on Friday night. Would that kind of “storing” be considered legitimate so long as the code is deleted as soon as it has been inputted manually on Monday morning?

In this instance (because of liability reasons) I would take the term ‘store’ to mean “any method of retaining the data longer than is required to send to the payment gateway to get a response of accepted or declined or captured” - including requiring to re-enter the card number on an invalid entry/being declined by the gateway.

But again, I’m not sure if the rules are the same over there.  Plus a large percentage of people in America are still sue-happy.  And I really wouldn’t want to risk losing my business that I worked long and hard on, just to make things a bit easier.

Store would mean collecting data for ANY period of time. Even if you save the details to a database for 30 minutes it would still be counted as storing.

Before I opted to go the gateway route, I used to process cards by hand. I was using osCommerce, but I used GnuPGP to send the middle 8 digits CVV encrypted via email. Technically, the email is storing the data as well, but at least it was encrypted. Since PCI compliance went into to full effect, I decided on a gateway.

This ended up being a lot more convenient, as most merchant accounts are providing an Authorize.net account with service.