Accepting payment best practices

Question

Hi everyone,

I am creating an ecommerce site that uses the payment gateway DPS. The payment gateway just takes a users details and returns whether the payment was successful or not.

I am just wondering if anyone has any good resources for how to make a really robust payments page that can handle large volumes of transactions safely. Are there well tested techniques and strategies for high volume payments pages?

Answer 1

I'm not an expert on payment processing and developing ecommerce applications, but some of my (commonsense) guidelines are:

1. Force HTTPS for the submission of CC information from users (pretty much all payment processing gateways force the use of SSL when communicating with their gateway);
2. Do not store Credit Card information in the database after processing;*
3. Follow general security guidelines (e.g. don't save plain-text passwords or e-mail passwords);

*Note:

PCI does allow for the storage of credit card details after processing, but you need PCI-compliant hosting, which is usually quite expensive. And even then you're running a huge risk. So if you decide to give your customers that option (and I know it's very tempting since big sites like Amazon all offer "one-click" checkout), you better make sure your application and server are locked down tight.

I don't know much about scalability issues with payment processing as I have no experience in that area. All of my applications only process about 5-25 orders a day.

Answer 2

Use SagePay (formerly Protx) it supports PayPal and allows you to take card payments. It also integrates into the Sage Suite (an accoutants dream) it can automate a lot of time consuming data entry.

www.sagepay.com

As others are saying - Sometimes for smaller sites it's not worth taking the risk of storing cards yourself. I prefer paying on websites where I'm redirected to a well known payment service (such as paypal, sagepay or google checkout) as i know that a lot of money is spent on securing this software. If you're a website that i'm using for the first time, well I'm going to be put off.

Answer 3

You'll want to design your code in such a way as took keep your data in a valid state.

The big liability you face is that you send data off for Auth/Capture, and then, for whatever reason, something on your end fails. You've charged your customer, but for whatever reason, you don't know this fact! Eventually, some irate customer is going to start shouting at you over the phone. That's a bad time.

The general idea is to put some safeguards in place so you can identify these kinds of problems. The problem should be very rare, if it even ever happens, so fixing the mess will probably be a manual process.

Here's what I would do:

1. Design a database table that tracks payments (let's call it "payment"), and relate it to your "order" table (so payment.order_id references order.id).
2. When it's time to interact with your gateway, set up a new payment record, containing any non-sensitive data you're about to pass to the payment gateway. Have a "status" column in your payment table, and set it to "pending"
3. Attempt the auth/capture transaction with your gateway. Upon receiving a response, update the payment record status to "approved", "declined", or "error" and save any relevant metadata (decline reasons, transaction ID, etc). If the gateway times out, that's probably just a kind of "error", though you might retry once or twice.

Run a cron job every now and then looking for payment records that are "pending", and older than, say, 30 seconds. If you find any, panic and tell a developer/operations person.

There are certainly other things that could go wrong, but this is the big one that comes to mind, and the strategy I've described is one I've used on multiple occasions to mitigate the risk.