I am looking to create an online gift certificate and sell these via paypal on a website for a restaurant.
The website is Wordpress / PHP based and will be using Gravity Forms / PayPal addon to capture the users details and take payment for the gift certificate.
I can create a PDF certificate which the customer will be able to redeem by printing and visiting the restaurant.
Now the problem lies with management of the gift certificates. e.g. what is to stop a customer printing off a gift certificate and redeeming it. Then next time they visit the restaurant, printing off the certificate again.
RoyalMail.com has some kind of DRM solution whereby online postage can be printed off once and only once.
How can I programatically protect my PDF files to only allow them to be downloaded / printed once?
For the sake of clarification, I do not want to know whether this is a good idea or not. I know that it is not an ideal solution. All I want to know is how to do it/if it is possible. No solution is fool proof, and people will always be able to 'forge' or duplicate the certificates. I just want to mitigate the possibility of doing so. Naturally there will be an in-house mechanism for checking redeemed certificates.
With regards to comment about spilling coffee on the certificate... AFAIK, if you put cash into the washing machine with your clothes, you have to ask the bank of england to re-issue you the bank note. You cannot re-print your own bank note!
There's nothing to stop a user printing off as many copies of a certificate as they want. But managing the certificates based on their physical copies is a really really bad idea anyway. If someone prints out a coupon and then spills their coffee all over it then do they have to buy another one? And what's to stop someone printing off their single copy and then running that through a photocopier?
If each voucher has a unique ID encoded in it, then all you have to do is record the fact that the voucher has been redeemed. Then it doesn't matter how many physical copies there are, if a voucher has already been redeemed once then you know not to redeem it again if someone else presents you with the same voucher.
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 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.
I've been curious about this for awhile and could never find any good information. I used to work at a pizza place that did online ordering. The user would submit their card information and we would run it at the store. I was wondering if someone could give me an idea as to how this transaction took place. If it was PCI compliant, and how it would be sent to the printer. I could think of a couple ways but none of them really seem to be the correct way. I'm looking to do this in PHP. Thanks.
If I where to design this system it would be like this:
The customer posts the order and CC information using a webform over a secure link to the server (using php to generate the page and take the info back in).
The server would use a payment gateway and bill the card on the server (server side PHP script).
On a successful billing it would contact a application running on a box at the restaurant with what to print on the order ticket (only the last 4 digits of the CC info is sent to the restaurant)
Updated with Chris's suggestion
Another option is to use PGP to encode the credit card on the server with the public key. When the CC is sent to the store, it can the be decoded with the Private Key and viewed in order to charge it. But when you are passing credit card information around like that, you always run the risk of something going terribly wrong. It's always better to use a gateway and charge the card immediately or authorize the transaction and then go back and collect the funds by running the authorization number.
I am selling stuff from here:
http://foundationletters.com/buy-master-mind-products/
One of the things on sale is a subscription to a specific website.
As you can see, I have connected e-junkie to my authorize.net account.
Let's say that I already have pre-generated accounts. In other words, I have logins and passwords that I am selling. I need to be able to convey them one at a time to every person that buys the product.
How do I do this?
I am sorry for such an open ended question. I prefer to not do much PHP / MySQL programming. Perhaps I can just have the person download a program that will automatically connect to a remote txt file from which it will grab an account?
But still i would need a placeholder, I would need to know which accounts are taken and which are not?
Please help if you have e-commerce experience selling "information" rather than physical merchandise using ecommerce with authorize.net
I think if I understand your question correctly, you want to be able to give people access to information/data (in this case, login credentials) upon completion of a transfer of funds (a sale), correct?
This is similar to a software license activation model wherein software vendor sells a license to use their software, the purchaser is given access to use the software by way of an activation key, product code etc. When done via. the Web, typically the seller, upon verifying payment from the buyer, makes the information available on the resulting Web page (usually called a receipt page). This is where the seller displays the sensitive data to the buyer. Customarily, on this page the seller will include a message such as "please print for your records". Additionally, it's very useful to allow the buyer to visit the Ecommerce site again at a later point to re-access the purchased information (if by chance they lost it).
Since you are selling "accounts", what your software could do (after payment is verified):
Generate a new username/password combination and store the credentials in whatever system depends on them to authenticate the customer later.
Display the credentials on the resulting Web page for the customer.
(optionally) Create an association in your database between the new "credentials" record and the new "order" record (not sure of your db schema, but using these names in place of actual entity names).
Hope this helps!
-aj