I have started working on a e-commerce website. This website will run PHP and MySQL and requires to have a credit system for the users; they will be able to pay with the credit, top it up by vouchers or regular payment, as well as withdraw.
Now I do have experience with credit cards processing APIs, so paying money in and out shouldn't be a problem; what however is a problem is how to securely store the credit information. Storing it as a single numeric field is not exactly ideal and potentially could be exposed fairly easily. What I was thinking is keep all the transactions and credit history of each user in a separate table, and every time they log in recalculate what should their credit be. Same would then apply before any transaction that they attempt to do.
I would like to hear what are your thoughts how this should be implemented.
EDIT: Just to clarify; my question is not on how to process credit cards and won't be storing credit card information. I will use a well known and secure API to process the payments (e.g. via paypal). However based on the credit card payments, I need to attribute the appropriate user points in a form of credit. These points would be a representation of funds on the website (whilst the money would be retained on the company account, until the user tried to make a payment/withdrawl) and would be used to make payments and withdraw funds. Again for the actual payment processing I would use secure API, however I am not sure how to implement the credit points properly from structural point of view in the application itself. I don't want to use a simple one field point system, as that I would consider very dangerous.
I hope that clears it up a bit.
Cheers
This might not be the answer you are looking for but here are my 2 cents.
In my personal opinion unless you have someone monitoring your dedicated servers 24/7 you should never in any format store credit card numbers in your database, it is just too risky.
A very nice solution I came across last year was BrainTree http://www.braintreepayments.com/. You can set up a very nice credit card payment system without taking on any liability yourself. Their API allows server to server and transparent redirect (form posts to their site and they redirect back to your site) transactions. At the same time their Vault service allows you to store credit cards on their end and you just use a token in the server to server API to process a payment. You can store the last 4 digits (which they provide in the transaction detail) in your DB along with the CC type and the token, with this you can display a drop down for the user to select which card they want to use and you just use the token when talking to their API.
The API is very nicely documented with full examples. I think you should look into them.
Edit:
I believe you should have a table as you have suggested to store all the history and 'totals' field in the users table, which can be used to display in various places. Each time a transaction a made calculate the total and cache it in this field for ready usage. However it is a good idea to re-calculate this in certain crucial places to make sure everything is in order. Even though this field is exposed but you have a full log which can help you re-calculate everything if needed.
Related
I am currently planning a new website for a local car hire company. They want a form where a user can input their personal details, select the car they want to hire and when they want to hire it etc. They do not want to take any form of payment on the website, but still insist on taking the user's credit/debit card details that they will then process on their card terminal at the time of hire when the customer picks up the car.
I have looked into a few options about how to achieve this, but keep stumbling on the card details gathering point. One option I have looked at is using WooCommerce (I am building on WordPress) along with this plugin https://www.wplab.com/plugins/offline-credit-card-processing-woocommerce/.
I am looking for any suggestions on a suitable and secure way of gathering the card details with this reservation form, with or without the use of WooCommerce.
Do everything you can to avoid taking credit card details, especially in the case where you're not actually performing any charges against them. Otherwise, you open yourself up to a whole new world of pain, the least of which is ensuring that your whole system design is PCI compliant.
I would try to find out why they think they need the card number ahead of time. When the customer gets to the physical location, the business will get a lower rate from the payment processor if they perform a card present transaction, which means it's actually cheaper for them to not collect the number ahead of time. That alone should be enough of an argument to sway them. If they insist on still taking the card numbers offline, hit them with a huge quote to make your system PCI complaint. It is no joke.
Use a secure SSL connection for a start!
Try a Credit Card validator such as https://framework.zend.com/manual/2.4/en/modules/zend.validator.credit-card.html
This might be quite a long read, because there is a bit if relevant back story. Of you just wanted to see the question summarized I have it written at the end.
Edit: I realize hiding the type of business isn't useful, it's a maid/cleaning business.
I'm working with a client where the service they provide is ordered through the website, but the client doesn't have to pay until the service is finished. Because of this the payment is handled through a third party and no payment information is even processed on the website.
The problem is now with the city. While we were in talks with them to obtain a license for the product they said that we could still collect payment the way we want, but we have to store(or have access to) a credit card for each user so we can identify or track them if they break a law (like assault one of our employees on the job or decide not to pay or whatever)
Originally we thought a fully varied phone number would be enough but they are insistent that we need to be able to link a user on the website to a credit card. Even if they choose to pay by cash we need a credit card on record just in the off chance we need to track them later.
Is there a way to do this without holding credit card information on our personal database? When a user makes an account can I ask for a credit card at that point and then just feed it to a service like stripe and just hold it there sort of acting like a second database? If we go through this route is there anything we need to do on our side in regard to PCI Compliance.
Our owner has had a bad experience in the past with bad developers holding credit card data on a server that was not protected and it ended badly so he refuses to hold any card information on our side Also the insurance we have already lined up refuses to back us any further if we hold it in site without professional security measures. Even if we did start to hold credit card information, what exactly do I have to do to make sure it's all secure and up to standard, I've never had to handle this before.
Any suggestions or help would be awesome I'm really stuck here.
TL;DR: City wants us to be able to link a user to a credit card before service is even started, so basically upon sign-up. Owner of business and isurance company doesn't want to save credit card information on our database. I'm not sure how to handle this and make both happy. Do I learn some basic encryption? Can I use stripe or something as a second database?
Edit: To clarify further, I don't want to use any of the information we save, we plan to charge customers differently. The city just wants it on record.
Yes of course there is a solution.
There are companies (Payment processing companies) that are doing exactly this, they charge a fee and offload all of the responsibility from you.
They invest a lot of money to be able to validate all of the security measures required by the law, including PCI compliance.
Those companies are not only offering different payment formats (such as single payment, recurring payments, etc..) but also takes care of storing some data on their side for future payments from the customer.
stripe, 2checkout and authorize.net are only a few of many options to look into.
Don't you ever think about storing any sensitive information (credit card information is only one example) on your own servers, unless you can comply with all security measures required by the law - which is a tiresome and expensive thing to do.
Good luck !
I am working on an API that can be used between my server and my iOS app. I have an SQL database that contains an Accounts table which includes a column called BALANCE.
People can make a real money deposit to my website through PayPal or I will be allowing them to send money orders. The problem is, when the PayPal SDK checks to make sure it was a legitimate deposit, then it credits that users account balance. When I receive the money order, I credit their balance via my website.
Each time the balance is credited, a call to my API happens. The thing is, I can do this over and over without actually getting PayPal deposits or money order deposits.
See, the users will transfer balances between each others accounts. So I don't need any help with making sure deposits were legit, I got that already. Right now a simple API call will transfer one balance amount over to another account without proof that the call was for a legitimate reason. I don't want to be able to have people somehow tap into the API and credit their own balance somehow. It needs to be where people can't just alter it.
So what can I put in place so that people cannot just tap into my API and credit their balance without actually sending money? Since this is real money, I am putting a lot of time into security.
You could authenticate with OAuth, which is what the majority of web service API's are using these days.
This tutorial may be of interest to you.
groupon.com is a great example when you register they take your credit card information. once a limited amount of people have purchased a coupon a mass amount of credit cards get charged. what is the best method of doing something like this and at the most safest possible way? one thing that i will be doing is encrypting the credit cards in the db with an encryption method that salts the encryption and that i can unencrypted it to use it when needed. would they possibly have a cron that goes through at a period of time to check and see if the coupon time limit has expired then do a mass charge? i cannot wrap around my head to how something can be written that queues transaction charges to a merchant. i am thinking of either using authorize.net or paypal pro.. what do you think from what ive said?
Don't store the credit card information on your server. It would need to follow PCI DSS security standards:
http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard
There's just no reason for it these days. A large percentage of payment processing vendors provide these services for you. You submit the information and receive back a token that can be used to charge the card at a later time.
Furthermore, you are not allowed to store the CVV code.
I personally work with Paypal as the processor, you need to request reference transactions (this will require a background check, probably credit worthiness related and is not guaranteed to be approved). In this way I can authorize a card ($1 authorization only is common and accepted practice) and later charge the card any amount that is appropriate (in our case we have a payment model similar to pay-as-you-go mobile phones). Upon the first charge or authorization I receive a token that I can late use to charge against the "referenced transaction" (essentially just copying the details from the original txn).
Another really interesting option that we looked into was www.paysimple.com, they now have a new API, an attractive pricing structure, and if memory serves, all of the above features.
Many others exist as well that you can and should research. Do watch out though, some card processing providers don't charge anything for the functionality described above (paypal doesn't), but some charge gobs of money for the service. Look, it's generally readily available info on the sites.
Start reading PCI Compliance and periodical payments parts of the source code of an open source cart like Magento. There is a lot to it, if you want to do it all properly.
I'm building an auction website that charge small fee for each bid.
There is option to buy bank of bids, and there is an option to pay separately for each bid.
When paying for each bid - I don't want to ask the user to re-enter the credit card info each time. On the other hand I'm surely don't want to store the credit card info on DB and I have read that it is not safe to save it as session variable, not to mention cookies.
The client credit card processing company can't store the credit info either.
All cc info is entered by user under SSL of course.
So, is it even possible ? Is there a safe (/safer) way to store the cc info in the session ?
Thanks
Most payment gateways now provide a service now where you send them card details, and they return a token id. When you want to perform an authorization, or take final payment against the card you just send the token id. This is hugely beneficial to helping ease the PCI-DSS burdens that come with taking payments by card, because you only store a benign token id rather than any card details.
This will allow you to capture the card details once, then authorize as frequently as you like. It's worth keeping the frequency as low as possible however, because the payment gateway will typically make a per-authorization charge.
With that in mind, how frequent are the bids? It may be worth summing up the daily bids that a user makes and then authorising/charging for them daily/weekly/monthly, or when a certain value threshold is hit.
there are parts of the credit card information that you can store in the database but this does not include CVV2 data (the 3 digit code on the back of the card). I believe all the information you can store needs to be encrypted - check for information here https://www.pcisecuritystandards.org/index.shtml
in my experience i found it easier to just set up real-time system and just get the customer to fill in their details each time - i found it to be much less hassle