4

I am looking at integrating credit card processing into a form. Basically what happens is :

  1. The customer will enter the website which is secured with ssl

  2. 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.

  3. Once the customer is happy with the price of their quote they press submit,this then posts the info to the payment page.

  4. 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).

  5. The credit card processor then returns a true or false value.

  6. 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.

Iain Simpson
  • 8,011
  • 13
  • 47
  • 66
  • 1
    Yes, that's essentially how it works. You rarely want to store credit cards yourself, it exposes you to lots and lots of potential liability. – ceejayoz Jan 20 '12 at 15:59
  • 4
    You're probably going to want to save the auth from the processor. You'd be wise to have the person you're working with read up on PCI compliance. – Bryan Naegele Jan 20 '12 at 15:59
  • When they said about storing the credit card details I said they would have to comply with the pci regulations so would have no chance using the shared hosting they have at the moment, so hopefully this will shut them up unless they want to spend lots of money on a dedicated secure server. – Iain Simpson Jan 20 '12 at 16:20
  • I highly doubt you'll get PCI certified on shared hosting. Most do rigorous port scans to ensure that nothing shows up, so having FTP or SSH open is an automatic fail. Remember that you don't need to spend lots of money on a server. You can get a suitable VPS for $20 a month, which might be less than you're paying for your merchant account. – tadman Jan 20 '12 at 17:17

2 Answers2

1

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.

Zoe Edwards
  • 12,999
  • 3
  • 24
  • 43
  • Thanks for your answer, I have heard a lot of good things about Sagepay so will suggest them as an option. I have told them upfront they will need an SSL certificate so they know what to expect on that front, I just wanted to clear up from grabbing the customers details onwards. Thanks :-) – Iain Simpson Jan 20 '12 at 16:15
-3

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?

dulac
  • 201
  • 1
  • 2
  • 7
  • Storing credit card data exposes you to usually unnecessary liability. Most payment processors support recurring charges by returning some sort of authentication token you can use to re-bill without needing to store their CC#. – ceejayoz Jan 20 '12 at 16:09
  • I never said it was a good idea. I simply said that storing CC# in a DB is not insecure. – dulac Jan 20 '12 at 16:10
  • Not inherently, but it does subject you to far more stringent requirements for ensuring security. – ceejayoz Jan 20 '12 at 16:10
  • Agreed. But that's not up to us to decide. It's up to their business to decide which Information Security Policies to put into place. If anything, there was SOME education and worth to my answer. Not sure it merits a -1, it's just not the BEST answer. – dulac Jan 20 '12 at 16:12
  • Thanks ceejayoz , thats handy to know, this is the reason they wanted to keep the credit card details on file, but I pointed out to them this would make them liable if they were stolen, your example sounds like a much more secure alternative. – Iain Simpson Jan 20 '12 at 16:13
  • In the US, it is also not just up to them to decide. PCI compliance can be a beast. And with some processors, it's a violation of their contract to store the number. But most importantly, storing a CC# in a databse is insecure. You've just given the CC# to your DBA, which is not something the customer agreed to, so you've already had a security leak. – ccoakley Jan 20 '12 at 16:19