4
votes

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.

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

2 Answers

1
votes

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.

-3
votes

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?