I'm taking my very first ecommerce site online. My client wishes to process their payments offline as they don't expect very much volume.

I'm concerned about security. I will have to capture and store credit card information, and I understand that this is a huge responsibility and liability.

Of course I'm going to need SSL during the capture phase, but what i'm most concerned about is storing CC information in our database until we process the payment. I'm hoping that encrypting it in the database and using good database password conventions will be good enough.

Can anyone comment or give any advice? I'm aware that using a gateway will free me of the necessity of storing the CC info. I'm trying to measure the feasibility of having a small business capture and store credit card information until it is processed.

thanks so much.

how does one handle offline payment processing then?

how does one handle offline payment processing then?

My recommendation would be don't -- use an online solution. With our solution you could do it offline using tokenization, but our tokenization solution requires the use of our gateway solution so offline processing would not buy you anything. I'm not aware of any other tokenization solution out there that would allow for this, and if they did, they most likely would have the same restrictions (otherwise, how long would a free solution survive?).

There are several solutions out there that either use tokenization or third-party payment provider. There may may be some confusion on the term "offline". What is their reasoning for offline? They may really want true book & ship where the authorization is done at the time of the order and the funding is done sometime later after the order ships. If this is the case, you are asking the wrong question and many gateways provide this capability.

Hope this helps.

they want to use their existing brick-and-mortar merchant account to process credit cards, and skip using an online gateway completely. No fancy process-now-charge-later or anything. Just run it manually through their own terminal.

I actually thought that this wasn't such a crazy idea, as the shopping cart software I bought has this functionality built in (PDShop).

Ok, I get that. Trust me, I hear you and it makes sense.

But for my sake please work with me to debunk my pre-existing notion.
Notion: There exist small businesses who are able to capture credit card information, process the payment offline using their own credit card terminals, and then destroy the information. All without the use of an online payment gateway.

By your logic this is simply never occurs. I don't know where I came up with this idea but I wanted to make absolutely certain that it is the common belief that this is not allowed and that this scenario never occurs.

sorry to belabor, but I wanted to make sure that I'm not misinterpreting anything and be as clear as possible.
Thank you very much for taking the time to read and respond.

Certainly don't try to work with off-line payments if you can help it. If the customer wants to do this then he'll need to contact the card provider and pay to get terminal access which is not cheap! For a small concern instead try a third party processor like WorldPay or similar.

They should not (actually can not) use their brick & mortar account to process ecommerce transactions. If any customer complains and issues a charge back, the merchant will have absolutely no defense and will lose and can lose the brick & mortar account as well.

The account has to be setup properly as an ecommerce account. The banks have fraud controls in place to track suspicious card usage. When accounts are not setup correctly, these fraud controls start throw false positives. For example, a cardholder makes a purchase in New York. Twenty minutes later the same customer makes a purchase on the web from a merchant in California that is incorrectly setup. Now the customers bank is alerted that a card was present in New York and 20 minutes later in California -- a physical impossibility (at least until transporters replace flying).

They should not (actually can not) use their brick & mortar account to process ecommerce transactions.

For example, a cardholder makes a purchase in New York. Twenty minutes later the same customer makes a purchase on the web from a merchant in California that is incorrectly setup. Now the customers bank is alerted that a card was present in New York and 20 minutes later in California -- a physical impossibility (at least until transporters replace flying).

I'm not sure if this is true Steve. Correct me if I'm wrong, but wouldn't the card need to be physically (swiped) present in both cases? A manually punched in number vs. a swiped transaction would equal two different things, right?

YES. PDshop can be set to capture payment details, and store it so that you can process it on your own later (using your own merchant tools).

HaterTot, I pulled the above mentioned quote off of the PDshop site, and your situation is actually more common than you might think. Magento Commerce offers an "invoicing" feature where they allow you to capture the customers CC info, then process the order later on, through a virtual terminal or physical terminal, if you like.

A search for "offline credit card processing" will bring up a ton of info for you. I suggest you take a look.

With that said, offline processing definitely does raise the question that you asked previously, "How do I safely and securely store customer cardholder data?" If you're not familiar with the PCI Security Standards Site, then I suggest you read through some of it as well. Including the "Quick Reference Guide" and the "PCI Data Storage Do's and Don'ts."

Basically, you're going to have two major security issues that you need to cover.

1. Capturing cardholder data.
2. Storing cardholder data.

Capturing cardholder data
This one is easy. Use an SSL certificate. You already knew that.

Storing cardholder data
This one is a bit harder...

PCI Security Standards are just that...standards. There are companies operating right now that don't adhere to those standards at all...why? Because it can be expensive. Just the words "cryptography", "encryption" and "tokenization" sound expensive don't they? But, if you want to avoid being dinged during an audit, and if you want to protect your clients business, then you have to go through with it. There are quite a few companies out there that will not only help you put together a secure system, but there are also some that will allow you to store your data on their servers instead of your own. Since it's their job to remain PCI compliant, you won't have to worry about securing your own database and network.

I don't think I can give you links, but here are some names:

TrustWave
Imperva
SafeNet
GroundLabs
ElementPS

It all depends on what you need and what your budget is. You may find out that going with a payment gateway is the better way to go. If so, at least you'll have built a nice case against processing offline to present to your client. Sometimes they need our guidance more than they know. ;-)

Hope this helps!

I'm not sure if this is true Steve. Correct me if I'm wrong, but wouldn't the card need to be physically (swiped) present in both cases? A manually punched in number vs. a swiped transaction would equal two different things, right?Incorrect, while swipe does play a role, there is a card present flag that is carried with the transaction for all transactions. Depending on the merchant type, the merchant setup, the processor, gateway, and the point-of-sale, this flag in many cases is overridden by one or more of the entities in the mix. If the setup is incorrect, non-ecommerce or mail order/telephone order merchants default this flag to true. For ecommerce and MOTO merchants, this value is always set to false. When a card is swiped, most of these layers are smart enough to assume the card is present and will set this value correctly to true. When the transaction is not swipe, the default value is usually used.

thanks so much guys. This has been a great help. I have been reading about PCI compliance nonstop for the past week and have also found that if your data is breached and you cause a problem for the CC companies, Visa (for example) will charge you 50k.

Thanks for clearing that up shift4sms. Good to know. :)

HaterTot, if you've been reading up on PCI compliance, then you're moving in the right direction. Best of luck to you.