I am looking at integrating credit card processing into a form. Basically what happens is :
The customer will enter the website which is secured with ssl
They enter their info into a form, and select different drop down options, jquery then updates the price of their quote on the fly as they select different options.
Once the customer is happy with the price of their quote they press submit,this then posts the info to the payment page.
The customer enters their credit card number, this is then posted to the credit card processor presumably using the credit card processors script ?, along with the price to be debited from the account. (not sure on this part).
The credit card processor then returns a true or false value.
If false is returned echo "transaction failed" , else enter the customers details into the database and display a success message.
What I am wondering is if this is the correct procedure to follow ?, as the person I am doing this for was talking about saving the credit card details to the DB or sending them in an email in a csv which sent alarm bells ringing, so I told them neither are a safe option and the processing should be done by the card processing company.
I just want to clarify that the above process is correct before I suggest an alternate plan to their highly insecure one.
The easiest way to handle this is to sign up with a payment gateway. They’ll have instructions on how to communicate securely with their server. The money is then sent to an internet merchant account.
You’ll likely then need a Secure Sockets Layer certificate for your site, in order to have a secure connection with the payment gateway’s server.
An example of a payment gateway in the United Kingdom and Ireland is SagePay.
Firstly, it's not "insecure" to hold such data in a DB. If you have returning customers and you want to offer them the service of not having to re-enter information ALL THE TIME, using a DB is an idea. To make the idea secure, you'll need policies in place for the DB administration, server access and proper data security (i.e. hashing, encryption, etc)
As for your script, if you are submitting the data via POST to the PHP script, the PHP script will certainly have to talk to a DB (whether is be your local one or the connection made to the Credit Card script).
To answer your question, you'll need to know EXACTLY what the script requires before making any judgement on what you need to do locally. If the script simply takes inputs and returns a value, then you'll have to integrate it into your WebApp.
More details if any?
Related
My problem is a client wanting to retrieve credit card details from there customers via an online form.
I'm aware of an SSL certificate been purchased and I've validated and sanitized the form fields which the user fill's in.
The issue come's up here when sending the card details, I'm wanting to send them via email to my client but believe that there will be so many security issue's doing it this way.
I guess my question is how would I send the cc details from the form straight to an email while maintaining security and if its even possible for it to be 100% secure?
Note there is know payment taken on the actual form its only purpose is to retrieve the cc details.
Thanks
It sounds to me like you've receiving a bulletproof safe, opened it, copied the details on a note.
Then you go outside, find an unknown boy on the street and pay him a quarter to deliver the note to your friend just a few blocks away.
And that is why credit card fraud exists...
Doing this is not only a very, very, very bad idea (you might as well not use SSL on the page), but it would also be in violation of the merchant service agreement that you (or your client) agreed to. You have to follow the PCI-DSS standard if you are handling payment card information and this is thing #1 on the "Don't Do This" list.
If you need to handle credit card details and don't have a security team, use a merchant service provider that handles credit card detail collection for you (such as Authorize.net, Paypal, Google Checkout, Amazon Payments, etc, etc.) With those services, you simply send the user to the providers site along with an amount to be charged and a list of items it is for. The third party deals with the credit card details and then sends you a receipt code that verifies the transaction and sends you the money.
The short answer is don't. Including credit card details in an email is a bad idea.
I am integrating PayPal Express Checkout API into a digital goods/services website. I worked out all the technical stuff, but now I have a theoretical question - when the transaction is done and I get a confirmation from PayPal, what is the best way to store that acknowledgement from paypal, and credit my user's account?
The ConfirmPayment() function in the paypal library returns from paypal with an associative array, including a transaction ID, and acknowledgement that I have the user's money in my business account.
So my plan is, store that transaction ID as a unique value in a SQL table, so if the user for example reloads the confirmation page, which would then re-call ConfirmPayment($token), my PHP script won't just credit their account a second time, because the SQL table will return a unique ID error.
How are smart programmers integrating this last payment confirmation into the rest of their application?
THANKS.
I would do it like so:
Keep a full log of all the messages your receive from Paypal. Just the RAW data should be fine. Then beyond that point don't need that much traceability. If anything ever happens you can check the log. This should really never happen, if you need to look at this log a lot to resolve any issues you have a different kind of problem. This is why my suggestion is: don't put too much time into it, but make sure you have traceability (albeit a very crude one).
If the user reloads the confirmation page, Paypal will not send you another message. Keep in mind that you should only accept transactions that Paypal has verified. The user should not be able to validate his own transactions by bypassing Paypal.
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.
How do you securely pass credit card information between pages in PHP? I am building an ecommerce application and I would like to have the users to go through the checkout like this:
Enter Information -> Review -> Finalize Order
Problem is that I am not sure on how to safely pass credit information from when the user inputs them to when I process it (at the Finalize Order step). I heard using sessions is insecure, even with encryption.
Any help would be appreciated!
I wouldn't store it anywhere. It's too much of a risk and probably not ethical.
Send a request to the payment gateway by posting a form over https and store the result of the transaction only.
You probably only care if the transaction was approved or declined. Who cares what the number is?
Don't store the credit card info in the session, don't store it to a database, don't store it to a file. Instead, write the cc info back to the review page in a hidden html inputs.
So the program flow would work like this:
User posts payment and billing information to the server via an html form.
Server verifies that this information is in the correct format (i.e., credit card has the appropriate number of digits, a billing address was entered, etc.)
After verification the server writes back all the information submitted as hidden form input fields. This includes billing address, shipping address and credit card info.
The form on the review page (with the hidden input fields) has a button labeled "Finish Order" / "Complete Order". This review form posts to the finalize order script.
The finalize script stores billing/shipping info in your database and submits the credit card info to your payment gateway.
The advantages of this method are two-fold:
You save the overhead and cost of additional PCI compliance that is required when storing credit info.
This method stays within the security bounds of the SSL protocol. Meaning, encrypted credit card info will have to be submitted to your server in any instance - this method continues to rely solely on the efficacy of SSL, without introducing the complexities of persisting credit card data.
This last point raises another concern - by having a review page you're doubling the number of times the encrypted credit card data is being transmitted across the network. With this method there are 4 transmissions minimum: client to server, server to client, client to server (again) then server to gateway. Without review there are 2 transmissions minimum: client to server and server to gateway. Is the convenience of a review page worth the risk of extra transmissions? That's a decision you as a web developer (and your client) get to make.
Well, first you should be using the HTTPS protocol to ensure that the connection is encrypted.
After that, you could store the data in the $_SESSION super-global. The data is stored on your servers, so it is relatively safe.
You could do a similar technique where you insert the information into an Order database, where the key is a GUID or something else fairly random and unique. Then, when the person goes to modify/review their order, you should have the Order ID stored in the GET part of the URL (or if you're paranoid, a cookie/session variable):
https://example.com/order?orderID=akjgflkhaslasdfkjhalsdjkljahs
To provide extra security, you could also store an IP Address in the Order Table, and make sure the IP and the Order ID match.
One alternative is to use a payment profile service like Authorize.net's Customer Information Manager (there are others too). You store the payment info in a profile via their API, then use the profile ID when actually charging the card. This way you're never storing the data on your servers.
Not my area of expertise, but I think you want to store it in a session but also use a "synchro token" (or whatever the kids are calling it these days) to help avoid CSRF attacks.
Of course, you want to be using https (correctly), avoiding sensitive data in the URL and hidden fields, avoiding putting very sensitive information in any response at all, etc., etc.
I think I will have to agree. Storing creditcard numbers is too big a risk and the consequences could be far fetched.
The ideal way would be to pass the information to a third party processor and just use the result returned to mould your script logic.
if (transaction){
// code goes here
}
else{
// code goes here
}
Hope you get the point ... :)