Leaderboard

This thread has already gotten really long winded so I'll try and conclude with some final cherry picked replies: PCI Compliance If you have a server in the cloud you simply can't be PCI compliant. You aren't really allowed to handle credit card data yourself -- but instead utilize the payment processor. This essentially reduces your concerns at the PCI Level 4 merchant level (or below) to doing a self assessment document. All you get from a payment processor, and will be allowed to store and use subsequently is tokens. Tokens aren't hashes either -- but are instead single use (nonce) keys that let you interact with the payment processor. At any point along the way if you are storing the original credit card input, you are at risk of running afoul of pci dss which you don't want. You can't store the cc info, even temporarily in a session variable to make the form process work nicely. This is one of the reasons that just about every modern payment process has a final step where the payment information is dealt with separately, and why the cc info is not retained between calls to the gateway. You wrote about how you would do subscriptions without doing subscriptions, which basically means that you will have to start messaging people about their pending renewal, and when it gets around that time, you will need to do a new transaction where they enter all their payment info again as if it was the first time. You kind of positioned this as a badge of honor, but it's a really poor decision for a subscription reliant business. I literally have never seen a single subscription business that involves that design. The hash in support of the ban tool You could go ahead and do what we've discussed, and take a piece of the cc# along with other pieces of name and address and make a hash and store it. You could also check against your own table of fraudulent credit cards and intercept a potential transaction before its sent to the gateway for that matter. You just can't store any of the inputs being provided to you persistently. Is a hash based on a piece of a cc# useful? Numerous people have pointed out the same issue, which is that people can have lots of different cc and cc#'s. The thing that Requinix described is not some esoteric product, but offered by large banks like Citibank, Capital One and Apple (backed by Goldman Sacks) to name just a few. It lets a customer go in and generate a disposable card#, ccid and expiration to be used for one or more transactions online. It's existence entirely defeats your hash. In fact it suggests that adding in any part of a cc# makes the hash less effective. Given these facts, assume you go ahead with your original idea. How will you create this table of "bad hashes" in the 1st place? Are you going to make a hash for every paid user stored with a flag that is 'ok' and then flip that to 'banned' or something like that? If that's the case then you would have with sha1 for example, to store a 40 character string in your database for every single user, just so that you can flip that on a handful of users at some future time. That's a lot of storage for something that would be used infrequently. Is a billing address required for ecommerce? I can only answer this technically having implemented e commerce numerous times with different vendors. With some of the largest payment processors in the marketplace, the address is not part of the input to the gateway. You may do with that what you will, but again, if I'm not shipping you anything then what do I need your address for? I brought up the gas station example, and your reply was that the card was present. That is true, but why then are they asking for the zipcode? It is because the card could have been lost or stolen. It's just an additional check. With ecommerce, the entry of the ccid is the equivalent mechanic that validates the card is present. You should also know that credit card fraud is *your problem*. Most of the payment processors offer their own fraud prevention services that you can pay for or not. There is no built in visa/mastercard/amex/discover fraud prevention system you just get automagically. Fraud = chargebacks, and chargebacks are bad for your business and will cause your per transaction costs to go up, or can even lose you your merchant account. Payment tech is changing Younger people are using mobile payment tech like apple pay, google pay, samsung pay etc. There is also a long tradition of alternative payment options, with the most prevalent being Paypal. Most people that take payments are going to support paypal, and you might also like to support these newer technologies at some point, and none of them have credit card #'s. Legalities There is a lot of state and federal consumer law out there. Just because you put something in a TOS that takes away someone's rights doesn't mean that will stand up in court. My final word If you want to do what you originally brought up, then technically it can be done. Requinix wouldn't if it was his company, and I wouldn't if it was mine. I just don't think it would be worth the time, effort, and storage cost, even though it could be coded up relatively quickly by someone who understood all the parts and technologies well. Furthermore, if I wasn't stuck in my house right now, I doubt seriously I would have continued to engage in this conversation given the mysterious nature of your proposed business. I don't want nor need to know what it's about, but I just have my doubts that there is any online community that people will pay for, when there are numerous well established online communities out there that are free. Usually the devil is in the details for any online business, and it's just not very fun or interesting to tech people to try and guess about what feature might help you enforce rules, without understanding the game afoot. Get your MVP up and running and then if you want, you can come back armed with specifics and actual real customers, and you'll find people a lot more enthused about your ideas, whether they be viable or not.