Posted by gordon on May 20, 2009 at 4:47am
Hi,
I am looking a little down the track and I was just wanting to gauge the interest in allowing customers to save credit card numbers for later use.
eWay (and I am guessing others) supports a method which allows users to save their credit cards for later use. Would people be interested in having a feature like this for their customers.
Also (forgetting patent isues) this would be the first step for allowing users to have single click purchasing.
Let me know if this is something you would like.
Gordon.
Comments
eway recurring payments
It would also allow you to setup recurring payment schedules. I'd certainly be keen to see it, but in the meantime have something similar planned with eway + ubercart (see http://drupal.org/node/459052).
Drasgardian.
saving half the credit card
YES offline processing of credit cards is something customers want.
I have a few zencart customers I could migrate to e-commerce on drupal if I got a payment
module that could do like zencart and store part of the credit card number and email the other part.
Many of you are probably aware how zencart/oscommerce does it.
The basic offline cc processor for zencard saves part of the credit card then emails the other part.
http://tutorials.zen-cart.com/index.php?article=67
There have been discussions about it this is good enough to meet the "PCI compliance"
Supposedly, your business is PCI compliant as long as you are not storing Track 1 CC data which consists of the full CC number, name, expiration date.
I tend to agree that it is very clear that you're not allowed to store customer credit card numbers in a retrieval system. The work around for offline processing is to save part of the number and email the other part. Many believe this will allow compliance.
SO LONG AS YOU NEVER collect CVV data if you are manually processing credit card orders! That is a no no.
PCI compliance does not
PCI compliance does not restrict you from storing the credit card number.
How do you think so many online merchants (such as Amazon) are able to bill customers on an ongoing basis without requiring the re-entry of card data?
Also, many other recurring billing systems store the full card number.
There are ways to do it,
There are ways to do it, obviously, but the restrictions are prohibitive for most e-commerce sites, especially people who don't maintain and secure their own or co-located servers. As I mentioned below, any number of payment gateways allow you to securely store credit card data on their PCI compliant servers and use reference IDs to charge those cards at later dates. Those services are what this this thread is about, not about local number storage. And PCI DSS do restrict you from storing the credit card number in conjunction with other sensitive card data, so it's not just a free for all.
You can be PCI compliant and
You can be PCI compliant and still store the full card number. Where are you getting your information that this is not the case? Are you saying that Amazon is not PCI compliant?
What about the PCI restrictions is "prohibitive"? They just have a list of security requirements for merchants who choose to retain the card data.
Also, you are one of the principals behind the Ubercart project, aren't you? - why do you seem to have such a strong interest in keeping credit card number storage out of Ecommerce project, when Ubercart allows the full card number to be stored?
You're not reading
You're not reading carefully. I didn't say what you're questioning:
"You can be PCI compliant and still store the full card number. Where are you getting your information that this is not the case?"
And the prohibitive elements I mentioned were especially in relation to people who do not control their own web servers (i.e. a majority of Drupal users). I don't care to debate the points here, and I don't care to debate an "Ecommerce project" vs. Ubercart point. This is a general e-commerce group, not a group specific to the e-Commerce project, and I wasn't being partisan at all. Finally, as I've mentioned many times before, Ubercart does not handle credit card number storage as you insinuate.
If you think Drupal needs a solution for long term local CC storage and re-use, have at it. At least at this point, I consider it a waste of time.
Perhaps I misunderstood this thread, but I thought Gordon's comments were related to using a service provided by eWay to store the credit card numbers there and charge them again at a later time. That is why my response was to point out similar services for such reference transactions offered by Auth.Net, CyberSource, PayPal, et al. My apologies to Gordon if I misinterpreted your thoughts and confused this thread.
Do you have any comment on
Do you have any comment on my post below describing how the issues related to retention of card data were solved by another system?
I guess I just don't understand why there is such resistance to retaining critical customer data for future billing, given that there are solutions out there that deal with the security issues.
Regarding storage of CC#'s
Regarding storage of CC#'s in the clear in Ubercart, I was just relying upon information on the Ubercart site (it appears that at one time Ubercart stored the CC# in plain text in the DB, but you are now encrypting it in some fashion, so I apologize for providing dated information)
Here are two representative links from the Ubercart site:
Ubercart forum post from an Ubercart user in 2008: http://www.ubercart.org/forum/general_discussion/3695/saving_credit_card...
"I noticed that the credit card is in my database."Ubercart online documentation (last paragraph of the section labeled "Credit Card Security"): http://www.ubercart.org/docs/user/2731/credit_card_settings#security
"credit card masking by default applies to all users of the site, but it is possible in your user access control settings for you to designate roles that can view whole CC numbers when they're stored."At this point you're
At this point you're trolling. There is more accurate documentation and discussion elsewhere, and I'll leave it up to you to find. Suffice it to say the first thread is from an unknown, confused user and you're once again not reading the doc page clearly or you'd see that it's referring to a debug mode (that still wipes CC data if a card is authorized or charged).
Not trolling, I just wanted
Not trolling, I just wanted to make it clear that I wasn't "insinuating" anything, just stating facts about Ubercart.
BTW, you still haven't commented on the Plesk/Modernbill solution I posted below...
You can be PCI compliant
No, but I would be fairly confident that Amazon is not storing the credit cards on their web servers, but instead on a back end machine which is behind firewalls encryption and a hole heap of other security restrictions, or they are just saving a token to pass to the payment gateway.
Yes Ryan is the lead of Ubercart, but e-Commerce does not store credit cards on the system because of Ryan trying to do any nefarious, but because I think that it is the worst idea in the world is store credit cards locally as it cannot be done securely.
I believe that anyone who does this is an idiot! not to put it to bluntly.
--
Gordon Heydon
--
Gordon Heydon
Hmmm... I posted some
Hmmm...
I posted some details about how one system does it below - I'm guessing you hadn't read that post yet??
Calling me an idiot seems a bit harsh, I'm just trying to add to the discussion. In your original post, it seemed like you were asking for feedback and suggestions, I am just throwing them out there...
Do you have any comment on my post below?
Not yet I am working my way
Not yet I am working my way though this list.
1 correction I did want to make is that because of how I have restructured e-Commerce there is nothing stopping someone from create a new payment gateway and saving the credit card locally. I know that I will not be using it.
--
Gordon Heydon
--
Gordon Heydon
Cool. It is good to know
Cool.
It is good to know that at the very least, the foundation is there to put together a custom solution.
I was not calling you can
I was not calling you can idiot directly, but feel that anyone thinks that credit cards can be stored securely from within CMS software really has not thought things though.
If you need to store the customer credit cards in a secure manor you would not be doing it within Drupal, but setting up a proper back office system to handle all the sensitive information, like credit cards numbers.
Outside of getting the payment gateways to store the card numbers it is a big step to being able to do it yourself with your own infrastructure.
e-Commerce is not limiting you from building up this infrastructure and providing the rebilling system which is completely locally. I am doing things this way that at the lower end they have options to implement this which is secure and doesn't require the implementation of tonnes of additional requirement, but is keep secure and so that when they want to move up to a higher end system where they will need to implement a lot more infrastructure to keep it secure and run it in the best way can as well.
I will not just provide systems that are really insecure just so they can short cut the system.
--
Gordon Heydon
--
Gordon Heydon
So you don't feel that what
So you don't feel that what Plesk/Modernbill is doing is secure?
Well I have not really
Well I have not really looked at to be able to say definitely but you either add additional processors that admins have to be available to do, or you become insecure. It maybe that it is not as insecure as I think, but it may add additional pressure on the store owner.
Ultimately I as a store owner I would prefer to have more time to sell products and less time doing administration. Also the fact that if you are not there to do the process, you cannot get the money, and also if you are late that is an inconvenience to your clients who are relying on a payment to happen at a certain time.
--
Gordon Heydon
--
Gordon Heydon
credit card security
Hi guys
Please forgive me if I say something here that has already been covered - I don't have time to read every message in detail.
I believe that you certainly can, with a bit of ingenuity and understanding how PHP and Apache work, store information securely on a web server. Whether it's a CMS or not is irrelevant. If you think that we could not design a cc security system that is just as good as what the banks use, then I suspect that you vastly overrate their technology and capability.
This back-and-forth of "yes we can", "no we can't" isn't especially useful by itself. What I propose is that, instead of claiming whether or not it's possible, we try to create a clever and secure method of encrypting credit card information, until we've proven it to ourselves either way. I am certain we can invent a system, operational within the Drupal/PHP framework, that will be just as secure as anything else out there.
No method will be 100% secure (and if you claimed as much, it would only be an invitation for a cracker to prove you wrong). However, there are degrees of security, and you can certainly make it exceptionally hard work for a cracker to access your info - indeed, more work than the value of the information.
Shaun
+1 I Agree.
+1
I Agree.
idea for securely storing cc numbers
I was thinking about this over the weekend, and would like to run this idea past you.
How about a reversible encryption algorithm that uses the plain-text password to encrypt and decrypt the card number? The plain-text password is not stored on the server, but is provided by the client when the user logs in. I don't know exactly the mechanism by which passwords are supplied for auto-login within Drupal, but I suppose it's via a cookie, and I also assume that defences against session hijacking have already been implemented.
Hence, when the card number is required, the password is obtained from the cookie, and used to decrypt it. If the user has cookies turned off, and if the password is not stored in the session, then they can provide their password - or their card number.
The advantage of this method is if the server is compromised then the card numbers cannot easily be decrypted, because the passwords are stored in the database as a hash, not as plain-text.
Of course, if the user fogets their password, they would have to re-enter their card number.
I think reversible
I think reversible encryption is the right idea, but:
*user passwords can be changed
*cookies can be cleared or expire
so an algorithm based on either of those two items might be problematic.
Also, I think any solution should be manageable independent of users/customers. When it is time to renew a user's subscription, the merchant should be able to bill a group of customers using the previously submitted card number. A user/customer login shouldn't be a requirement.
Something like the public/private key encryption used for SSL might be ideal for this type of scenario, with the "private" key being stored on the server (and used to encrypt the customer's CC# and write the encrypted value into Drupal Ecommerce). The "public" key would be retained separately from the server by the merchant in a secure location (and used to decrypt the credit card when rebilling customers). The system could be designed so that the public key was never written to disk on the server, and was removed from memory once any credit card processing activity had been completed.
What do you think?
Keep the private key private
It sounds like you have the keys mixed up:
* The private key must be kept off the web server to prevent its being compromised
* The public key goes on the web server where it doesn't matter who gets it
Besides, you cannot decrypt using the public key - that's the whole point. The public key is there to distribute to everybody whom you want to send you encrypted messages (by encrypting them with your public key). Nobody can decrypt those messages (even with a public key) except the holder of the corresponding private key (hopefully only you).
You are quite right about the suitability of asymmetric keys here. In the days before SSL and proper certification, I wrote a Java applet that contained my public key to encrypt customer card data. This data was later decrypted on my offline server with the corresponding private key to effect billing.
You are correct, but there
You are correct, but there is no way to secure this information in PHP if the site is hacked. Even with using things like encryption, a hacker can just decrypt the card numbers, since all the information to do this will be required on the site anyway, as the card gateway will need to decrypt it.
This is what puts this way out of the reach of the average person who wants to set up a e-Commerce system.
--
Gordon Heydon
--
Gordon Heydon
Some other billing systems
Some other billing systems manage the security of the card data by combining a server key with a client key. It's simply not true that PCI compliance negates the storage of credit card data. No customer with any sort of sizable customer base is going to want to rely upon a 3rd-party gateway - if you read the agreements provided by the gateways, they are very restrictive and allow the gateway to sell the merchant's customer list out from under him in most cases. Also, if the gateway goes under, all of the merchant's data is lost. There is also no price protection - once a gateway has enough of a merchant's customers card numbers, the gateway can raise processing prices and the merchant has no recourse. Lack of rebill capabilities will almost certainly ensure that Drupal ecommerce will only be a small-scale solution, used only by merchants with few recurring customers since forcing customers to re-enter their payment details every time they make a purchase is a sub-standard user experience that lowers retention rates, and makes it more difficult to upsell (why do you think Amazon offers "one-click"?)
It is worth taking a look around at what other (commercial) billing systems are doing, before rejecting storage of card numbers out of hand...
Modernbill has done it this way for several years if I'm not mistaken. Other recurring billing systems also have found ways to store the data securely.
Here are a few details about Modernbill's setup.
http://cc.bingj.com/cache.aspx?q=modernbill+credit+card+encryption&d=760...
http://www.modernbill.com/support/manual/old/v4/adminhelp/english/Config...
Decryption of the credit card data requires a site admin to log in and enter a decryption key, which is used to decrypt credit cards as they are billed - decrypted value of the cards is never stored in the database, and even if the server is compromised, without the admin's private key they can never be decrypted.
Here is a link that was posted on the Ubercart website regarding PCI compliance (basically it confirms that storage of card numbers is allowed) : http://www.webhostingtalk.com/archive/index.php/t-865713.html
I never said that storing
I never said that storing credit card locally would break PCI compliance. But the liability is something that concerns me and I would not recommend clients do this.
But also given the point that if a payment gateway goes under, and all the billing information would be lost is a good point.
But the fact that not providing methods of rebilling by storing credit cards locally is not going to limit the people who will use it. and moving up to a size where rebilling is an issue then you would look at storing the credit cards on a back office server, and not the web server, so the web server can access it much the same as the you would a 3rd party gateway. Most banks I have seen provide this type of software which you can do this from a back end server.
--
Gordon Heydon
--
Gordon Heydon
RE:"moving up to a size
RE:"moving up to a size where rebilling is an issue then you would look at storing the credit cards on a back office server, and not the web server, so the web server can access it much the same as the you would a 3rd party gateway. Most banks I have seen provide this type of software which you can do this from a back end server."
I was doing some looking around - it looks like that may be the way that Rodopi (http://www.rodopi.com/)does it. They offer interfaces to IC Verify and PC Authorize - either can be installed on a separate Windows PC, where clients can run transactions directly against the credit card network (data stored in a SQL Server DB)
Yes it is encouraging the
Yes it is encouraging the store owner to implement this properly in a secure method. So with ec you can implement this as a new payment gateway to talk to the other box.
--
Gordon Heydon
--
Gordon Heydon
Hey Gordon, I think it's a
Hey Gordon, I think it's a great idea and it's something happening elsewhere in contrib space atm. I've done similar work w/ CyberSource, Authorize.Net, and PayPal. I tend to refer to them as reference transactions since the gateways can't decide on their own standard terminology. My biggest mistake in the implementation was storing the reference IDs at the level of the order instead of the user. Silly data handling mistake, but it was guided by the fact that I couldn't change the CC API to better accommodate the multiple CC transaction types at the stage of the game when I implemented it. :-/
@webengr - those methods are outdated. These gateways allow you to securely store CC data on the gateway server and store a reference ID that you can then use to process transactions at a later date as if the customer just entered their CC info. It's secure and PCI compliant.
outdated
yes and some people are still using microsoft frontpage server extensions.
Try telling a customer they are outdated... ;)
While 'outmoded' some customers only have a terminal and may have a few transactions to begin with and do not want to setup a gateway. YES I realize that they should cough up the $25+ a month to gateway. But in many cases the customer wanted to wait and use a hardware terminal like a phone call to process. I warn them they are in the PCI compliance danger area and to be careful how they kept the card info physically in their office! - but yes a heck of a lot of small stores are still hand typing the card info into a terminal at 300 baud... even with a website. ;(
Yes I misunderstood the thread, being the 2nd to post. This thread is not about off line processing, but recurring. - Apologies.
However I should listen in about recurring since I need to look the updating the linkpoint interface for drupal 6 version. I realize the gateways do have an interface to save credit cards, if you have the gateway setup and not just a hardware terminal, I have had to use linkpoint and I did cobble together a module to support e-Commerce, and an authorized drupal project to do so, and yes I did not do recurring but had thought about it and decided to tell clients to use the linkpoint virtual terminal for now rather than cart. http://drupal.org/project/ec_linkpoint
I reckon the split the card thing if added should be a contrib module, which I don't believe has been done yet, and Gordon has enough on his plate... yet another todo someday... else those few customer stay with zencart.
1st Data/linkpoint/yourpay - no go on saving card numbers
I had conversations with linkpoint development support (1stData)
and to be sure called again later, and on both occasions while helpful,
the tech said that that linkpoint could not store a credit card for
future uses, unless it was for a recurring order or a future payment
for a fixed order number and price.
The tech said he would suggest it for future features after I stressed
that I read that it was supported by tokens in some other payment systems.
SO NO GO on this for 1st Data / yourpay / linkpoint
for the near future.
And look like I may want to be a var for authroize;.net if they do this token thing...
yeah zencart - turn off cc
btw, if you do use zencart to split the card,
be darn sure to turn off the option for storing the numbers on back of card!
This is not so much a
This is not so much a reference transaction as the amounts can differ from transaction to transaction. This is not really for scheduled payments as this can happen at any time and for any amount. Like paying for a service in advance, based upon some random criteria.
I had this answered for me as I need for a project. Basically if you think of slice host, you purchase a virtual machine, if you change the plan for the virtual machine, or add more servers then your need transaction is going to change in value.
This would most likely be used for services billing, but could be used to allow credit card less transaction for a save credit card.
--
Gordon Heydon
--
Gordon Heydon
The option of saving the
The option of saving the credit card number is critical for recurring billing IMHO. Also for fast, easy, 1-click upselling of existing customers. Reliance on 3rd-party gateways is not practical once you get to a decent number of customers.
There are ways to manage the security of the credit card data - other recurring billing software packages do it.
encoding credit card numbers
The issue with card numbers is obviously storing them in plain text in a database. I have written a few reversible encryption algorithms, which would be suitable for credit card numbers. Of course, the PHP code could be lifted from the web server and the algorithm reverse engineered. However, you can store certain key numbers used by the algorithm somewhere outside DocumentRoot (in a root-only accessible file), and provide them as environment variables, increasing security.
This is all well and fine,
This is all well and fine, but if your system is compromised all bets are off. You can have all the card numbers as encrypted as you need to decrypt the card numbers to use it for transactions a hacker can do the same. All the information is there to decrypt it.
This is exactly why any payment gateways are providing facilities to save credit cards on their system so you can use it later. Using this method is that worst case they can only create additional payments to your system and cannot use the token to make payments anywhere else.
--
Gordon Heydon
--
Gordon Heydon
I don't know what the big
I don't know what the big deal is about. I just keep a file called credit-cards.txt in my home directory that has all our clients' card info in it. When I need to re-bill a client for something, I just log in (my password is the name of my first pet when I was growing up, so nobody will be able to guess it) and grep the file for the clients' name. You say yourself that the encryption is pretty much useless if our system gets hacked, so why bother? And our server hasn't been hacked yet, so it must be pretty secure.
(THE ABOVE IS A JOKE. If you found yourself nodding and going "mmm hmm, I agree," please let us know the URL of your web site. Also, here's a fun game: You can find out your pimp name by combining the name of the street you grew up on, the name of your first pet, and your mother's maiden name! See, mine's Eleventh Fuzzy Randall! Ha ha ha, what's yours?)
The Boise Drupal Guy!
please see post above "Some
please see post above "Some other billing systems..."
Many commercial systems have figured out how to do it. It's a solvable problem that has been solved in a variety of ways. It's worth checking them out.
Implementation Idea
I was thinking about it more and because of how I built the receipting system in e-Commerce it doesn't actually need to be paid to a transaction.
So given this I could actually write a services module and expose the ability to take make payments via a service call. So you would have 2 Drupal systems. The front end web site with all your products and cart etc and then a payment gateway which would make a REST/SOAP or even a JSON call to the back end server where the actual payment will take place.
You would restrict the firewall to only accept calls from the web server and you would also put this into a SSL connection.
So given that your server that makes the payments is behind a firewall in your local office you can save the credit cards to the database to allow recurring payments or new payments as you will have all the information to make more payments.
You could actually also do this with an ubercart front end, but you would need e-Commerce running in the back office to make the actual payments.
Also there would be no restriction on which payment gateway you would use as long as it is an API based method like authorize.net, eway or even paypal pro.
--
Gordon Heydon
--
Gordon Heydon