Forum Moderators: buckworks
I have been asked by a client to update some sections on their e-commerce website, and one of the areas requested to be changed is their payment processing section.
At the moment they offer 3 options:-
They want me to enalbe them to take credit / debit card payments using a payment processing company like worldpay. Now I have never used any services like this, so don't know where to start. Ideally they would like the user to be kept "on-site" and not directed to another website to complete payment.
The customer already has a card processing system in store, and has a merchant account to allow them to do mail order sales, so does this make a difference? He has asked if its possible for him to capture card details from the customer when they "checkout" and to process the sale on his terminal in store, but again I don't know if he is allowed to store card details etc on the website?
Can anyone shed any light on what he is / isn't allowed to do, and also what options we have?
Many thanks guys!
I recommend Protx because they are much cheaper than Worldpay and their integration is a bit easier. I have been using them for over 3 years without much problem.
The benefit to an off site CC facility like worldpay or secpay is that you don't have to worry about being PCI DSS compliant, but the down side is that the customer has to go off site.
but the down side is that the customer has to go off site.
If you configure the payment processor correctly, they shouldn't.
What you do is write or install a script that does what is called a "silent post." Using a program such as curl (Linux,) you post to the processor and parse the results. So your checkout script program operates like this:
1. Post form to script over SSL
2. Script uses curl or some other method of secure post to connect to the secure processor over SSL and gets a result. A typical command is $result = `curl -d [your form data] [your processor URL]`, where the response from the processor is stored in the variable $result.
3. Depending on how the returned data is formatted, you parse it out to extract the response.
4. If the order is successful, you update your database, send emails, etc.
5. Finally, you return a response to the browser, successful or otherwise.
All this is done from one on-site script, you never leave the site. Each payment processor will have in-depth instructions on integrating their system through various programming languages.
One other tidbit - most often, an online merchant account is required as well as a payment gateway. You post to the gateway, and the gateway connects with your account. Some processors have this as an all-in-one, which makes life a little easier.
About taking credit card numbers over the Internet: the previous outline relinquishes you from the responsibility of maintaining credit card security. As mentioned, PCI compliance is required by the credit card companies if you store credit card info:
PCI Compliance Guide [pcicomplianceguide.org]
In short, this requires an audit of not only your web site for security, but all the systems in the process - the OS, the network on which you reside, and the server. This is beyond the means of most merchants, which makes an online processor the most viable option.
Additionally, if the client reads his merchant account contract, they are very specific about how it is to be used. If you are caught processing orders collected over the Internet with an offline account, PCI compliant or not, you will most likely have the account terminated and can be fined in arrears.
so don't know where to start
You can skip the SSL cert if you do as Jack_Hughes says - at checkout, you send them offsite to the processor. This creates some difficulties in implementing step #4 above, and also doesn't look all that professional - but a lot of companies do it.
We do not store credit card details, we just send them off to secpay via XMLRPC but we have had to become PCI DSS compliant.
If you don't want to become PCI DSS compliant then use an off site service provider.
