Forum Moderators: buckworks
Their background is industrial parts, made to order. Currently they discuss details on the phone, then take the payment on a terminal.
They want the most commonly asked for items to be available to save their phone operators time.
My plan was to have a shopping cart/e-commerce style frontend on the web. The card and address details would be stored on a database. Telephone bod then processes the orders using an admin interface in the office on his terminal.
I'd also like to know a good way of encrypting the data in the database, just incase someone manages to break in, you never know.
I haven't done e-commerce before, just getting into it, I'd like thoughs and suggestions doing it this way as I can hopefully use it in the future for people who already have their own terminals.
But it can be done, and often is, it's just not safe. :-)
Ack, fixed it :-)
[edited by: rocknbil at 7:09 pm (utc) on Aug. 30, 2007]
Forgive me for being dumb, but what's PCI?
(told you I was just getting into it! ;) )
PCI compliance (Payment Card Industry Data Security, or PCI DSS) is an audit reviewing 12 requirements [pcicomplianceguide.org] to verify security of data and is required by credit card companies for anyone who stores credit card information. Your network, data transmission, and storage methods must be audited and approved to acquire PIC compliance.
It's easier to just use appropriate channels (Internet payment gateways.)
At no time should a merchant or service provider store the card verification code or PIN verification data elements
The website where I get all my computer stuff stores my CVC, along with all the rest of the card data so I don't have to enter it every time.
According to that, they're not supposed to?
ok then, read up on the requirements, it doesn't seem all that difficult and most of it is really common sense. I mean, who doesn't run anti-virus anyway?
If a wireless local area network (LAN) is connected to, or is a part of the cardholder environment, Requirements and Testing Procedures for wireless environments apply and are mandatory.
I liked that one. Notice it says 'cardholder'. A lot of people now have wireless t'internet at home. I can detect 4 unsecured networks from my front room, let alone changing the default SSID's and passwords.
Do they really expect people to get their home network tested?
Anyway, all that aside, it seems like far too much bother and paperwork for a simple back-office system. So what's the alternative, get them to scrap the swipe and build a proper online payment system they can use instead?
How do I go about getting started with that?
it seems like far too much bother and paperwork for a simple back-office system
However I read on here somewhere you're supposed to keep the numbers for a couple of years for some reason.
Well the idea was to delete the numbers off the database once the order was complete. That way the most they'd get is a few that hadn't been processed yet.
Doesn't help if they get a root-kit on your server - then they can spy on all the transactions as they come through..
Your best bet is to integrate with a compliant gateway provider.
It doesn't look like too much hassle, most of the requirements for PCI can be done if you create a spur off your DMZ, with a firewall, and only the DB server with the card details behind it.
The firewall then only allows HTTPS traffic from 1 IP address - your web server.
Your web server is then locked down so only HTTP/HTTPS traffic can access it, thus preventing any sort of intrusion really.
It's extremely strict, but better safe than sorry. The only way to access the webserver then would be an IPsec tunnel.
Of course you'd still have physical access to the server if you need to log onto the terminal for any reason, and the IPsec tunnel should be secure enough that only certain users can upload files.
Have any of you guys set up your own PCI compliant servers?
The website where I get all my computer stuff stores my CVC . . . According to that, they're not supposed to?
Doesn't sound like it.
Do they really expect people to get their home network tested?
I don't know if that's the interpretation, I think the general rule of thumb is for merchants and anyone else storing credit card info.
So what's the alternative, get them to scrap the swipe and build a proper online payment system they can use instead?
Well this is one, as most payment gateways can be used as "virtual terminals." But processing a card that way is far more expensive than a CP swipe. Some Internet accounts can integrate you with a swipe terminal of their own. Or you can have two accounts, one offline and one online - we opted with this one because when we got into ecommerce, we were already into a contract with the offline provider.
Well the idea was to delete the numbers off the database once the order was complete. That way the most they'd get is a few that hadn't been processed yet.
You can do that, and encrypt the data, and maybe even set up so your network is PCI compliant - but there is still one catch. The offline merchant account provider. I know in our case, it specifically forbids using that account to collect credit card information via the Internet. So even though your methods are secure, your clients can still get slam-dunked with charges in arrears and fines if the scheme is revealed. Basically, you are using secrecy to circumnavigate the terms of the contract.
Real world: if you apply your security knowledge well, chances are very good no one will get caught. Like doing 75 in a 65. :-) But the penalties are a lot stiffer than speeding . . .
However I read on here somewhere you're supposed to keep the numbers for a couple of years for some reason.
I **believe** there are two dimensions to this, but have asked about it a lot and and still asking, so don't hold it as fact. If you are responsible for processing transactions, such as a bank gateway, you need to maintain the info to be able to provide refunds and chargebacks. For an actual merchant, I don't know that this is true - in the event of refunds or chargbacks we always log in to the bank account or merchant account interface. The only storage of CC info we maintain as a merchant is for our offline terminal - we keep the store-copy receipts, which contain only the CC number, and we keep them for tax purposes only. Off-site.
A compliant gateway provider is actually not enough. In order to be PCI certified, a hosting company has to have data vaults set up for hosting credit card info.
Can you elaborate on this? If you're using a PCI compliant gateway, you're not storing CC info in the first place, correct? Or are you saying this in reference to storing the info and charging later, as in a subscription renewal?
A compliant gateway provider is actually not enough. In order to be PCI certified, a hosting company has to have data vaults set up for hosting credit card info.
Can you elaborate on this? If you're using a PCI compliant gateway, you're not storing CC info in the first place, correct? Or are you saying this in reference to storing the info and charging later, as in a subscription renewal
Ummm, that wasn't my comment, but ok then, I guess the CC numbers don't actually have to be stored, never really thought of that! Just assumed that I would store the numbers. So the best way of doing it is to take the payment using the gateway, then dump the number?
Your explanation of the gateway provider's requirement to store the numbers seems much more feasible.
Do they really expect people to get their home network tested
I read a bit more into that, assuming they're using SSL, the connection is considered secure, even if their network isn't.
I guess the CC numbers don't actually have to be stored, never really thought of that! Just assumed that I would store the numbers. So the best way of doing it is to take the payment using the gateway, then dump the number?
Just want to clarify that I think rocknbil is talking about a system where you never see the number at all. You hand the customer off to the gateway, and the gateway hands them back and tells you that payment has been authorised or not.
This is my understanding anyway - your webserver is then irrelevant from a PCI compliance point of view. The downside is a lot less flexibility.
Just want to clarify that I think rocknbil is talking about a system where you never see the number at all. You hand the customer off to the gateway, and the gateway hands them back and tells you that payment has been authorised or not
Yes that's what I meant, just didn't explain very well.
I think in this case that's probably the way I'll go, I don't want to be the next TK Maxx!
Thanks for all the advice!
PCI is not just one thing - it's a process. If a hosting company says it is PCI compliant, that does not mean you are.
Usually spending the extra $20-$40 a month for an Internet merchant account is better and easier in the long run
-Corey
Since the CVV2 / CVC2 / CID has already been verified, no need to do it again
Thanks for clarifying that Corey.
Since my client produces bespoke products, and very rarely has repeat customers, I have talked them into the fact that there is really no need to store any customers data.
I'm going to just take the order details, and the contact details, then someone can call them back to discuss their product and take payment.
Thanks to all who participated in this thread, I really have a lot of info, and certainly enough to now spend the time to build a good e-com system.
