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 !
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
I'm working on a project with a new client and they've had some problems getting a merchant account for processing their online payments due to the business type. The system works in a similar way to Just Eat/Expedia etc in that a customer places on order on the site which is then passed on to the venue, with the site taking a commission.
The client asked if we could store customer payment details in our database (encrypted) and then pass them on to the venue for processing themselves using their in-house card systems. I know there are PCI Compliance issues with this but I've not been able to get a straight answer on exactly what we need to do. I've spoken to a couple of hosting companies and one is saying we need a cluster with separate web and database servers, while another has said we won't. I've never done something like this before, I usually just farm out payment processing to somebody like SagePay etc.
This is the proposed payment flow:
Customer places order on website
Payment details are stored in database
Customer is emailed an order acknoledgement. Venue is emailed an order notification. If venue accepts the order, order and payment details are transmitted for in-house offline processing
Once the venue has taken payment in-house, the order is confirmed and payment details are deleted from the site database
Customer is emailed a final order confirmation
I want to make sure any process is right, and the last thing I want is for the site to be attacked, payment details taken, and be left liable for any losses!
Any advice would be much appreciated.
You failed to include an actual question....
However: PCI compliance is non-trivial; there are multiple levels of compliance, and the standards are a little dense...in general, as long as you don't store payment details, it's relatively easy to comply. If you do store payment details, your compliance requirements become a lot more complex, and may include processes such as vetting employees.
Your intention to transfer payment details to the venues looks like a huge red flag - you're basically giving credit card details to third parties, which I as a consumer would not be happy about, and is almost certainly not allowed within any of the PCI standards.
It's worth talking to a specialist payment gateway provider about the options you have - for instance, most credit card transactions consist of an "authorisation" call, which submits the card details and amount; the service checks the card is good for the money, and "ring fences" the amount on the account, and issues back an authorization code. The actual "settlement" can occur later - up to 10 days for some cards, and can use just the authorization code, rather than the full card details. A specialist payment provider will know what options you have.
It may be possible for you to share the authorization code with your venues, to allow them to take payment (though this would almost certainly require you all to use the same gateway provider).
It would be straightforward to change the flow you mention to include auth/settle logic:
Customer places order on website
Your site issues "auth" using credit card details, store auth code.
Customer is emailed an order acknoledgement.
Venue is emailed an order notification.
If venue accepts the order, you execute the "settle" transaction
You confirm order details to venue
Customer is emailed a final order confirmation
Weekly/monthly/whatever you issue a report to each venue showing amount outstanding and send them a cheque or whatever.
An alternative approach is to take the storage of credit card information out of your hands completely and put the burden on someone else who has the means and expertise to do so while making it easy for you to charge your customers when necessary. Authorize.Net offers their Customer Information Manager API which allows you to create payment profiles for your customers. They handle the storage of the credit card information and give you a payment ID for it. You then can charge against that payment ID whenever necessary without having to have access to the actual payment details.
I am capturing the credit card details from the uses in a form and then sending these form data to payment gateways like PayPal or Braintree.
The credit card capturing form is hosted in SSL (HTTPS) and using cURL to post credit card data to payment gateways. As we are not saving credit card data to our server so do we need to be PCI complaint if we are following this scenario.
You shouldn`t do that!
The form that handles the credit card information should always point to the payment gateway as target so your server doesn´t handle any sensitive data.
A good payment gateway will send you back a shortened version of the credit card number combined with the verification status to store in your database and possibly show the user in emails or user admin areas.
You could also use a javascript to get a shortened credit card number (and the number only!) from the form and send this via ajax to your server before sending the form to the gateway.
If you're handling and transmitting credit card information then you have to be PCI compliant. Period.
I agree with the two other answers that are posted ...
As you have access to the sensitive data, functioning as a man-in-the-middle, regardless if you decide to store the data or not ... you could ... and you need to be compliant.
If you pass them on to another form which isn't yours like Paypal / etc. and you never actually receive any client credit data ... that is the right way.
The Smart Approach to PCI DSS Compliance
http://www.braintreepayments.com/services/pci-compliance
By using our Transparent Redirect (TR) and Vault, merchants can achieve PCI Compliance in days. TR and the Vault will eliminate the handling, processing or storing credit card data so you can qualify for the Self Assessment Questionnaire A, the shortest of the four SAQs.
Probably, you are still handling the sensitive data. If someone hacks your server they could easily intercept your communication and get hold of this data, i.e. it still needs to be properly secured.
You will probably find the correct answer on the PCI Website
The short answer is yes. There's several levels of PCI compliance, all of which are determined by your annual sales volume.
Most merchants do less than 20K transactions annually and that affords some liberty to do a self-assessment to confirm that you are compliant with the regulations. This article, although Magento specific, is a really good summary of the landscape.
The key takeaway here is that you should have this as part of your core business workflow.
The answer is NO, you DO NOT have to be PCI compliant if you aren't storing credit card details and using a secure gateway. But, you DO need https which you already have.
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.
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.