Storing Card Details / Queueing Payments

middleman666

Hello All,

I'd like to be able to process a large amount of transactions in a short amount of time, possibly thousands per minute.

Trouble is the payment gateway company we are using struggles with anything above 240 per minute (average of 4 per second).

My solution or at least the only solution I can think of, is to hold the card details in a queue table on the database then have a CRON job running to go through and process them at a rate the pament gateway can handle. After the transaction has been confirmed by the payment gateway I would delete the card details from the queue (this is the only place they would be stored).

The card details stored would include everything required for the transaction including the security code on the card.

If it was possible I wouldn't store any card details at all.

Does anyone have experience on storing card details or any other options you think I could use?

Cheers

knowj

Just to throw a spanner in the works have you thought about the issue of 3D secure if your handling the transaction after the user has left the site they are not there to validate their 3d secure/card holder present.

Have you considered another payment gateway. Some companies offer custom solutions that may be able to handle the amount of requests your dealing with.

On the queing payments I personally haven't dealt with this. However unless I was confident the server was as secure as possible and monitored I wouldn't like to store card details.

However if you are going to at minimum use a salted AES.

middleman666

My transactions don't require 3d secure validation so that won't be an issue.

Haven't got a big enough time frame to source another payment gateway for this project which I know is a lame excuse, but it's just not a possibility at the moment.

I'll have a read up on AES, cheers.

sneakyimp

I'm curious how you are cramming this enormous volume of transactions through to the gateway. If you are trying to process them sequentially with a single cURL object in a loop then you are never going to get any reasonable speed. At the very least you should have a scheme that supports concurrent requests between your system and theirs.

middleman666

sneakyimp;10944752 wrote:
I'm curious how you are cramming this enormous volume of transactions through to the gateway. If you are trying to process them sequentially with a single cURL object in a loop then you are never going to get any reasonable speed. At the very least you should have a scheme that supports concurrent requests between your system and theirs.

When storing the transaction details to the table queue I've also setup a QueueID field which holds a random number (1-4). Then I have 4 different CRON jobs running, each working on one of the QueueIDs. Obviously I can ramp this up to process more at the same time, but it's dependent on the payment gateways response speed.

sneakyimp

There's an important difference here between latency and throughput of the payment gateway. You may have four instances of a single script running, but if each script is only capable of doing one transaction at a time, then you probably aren't coming anywhere near the theoretical performance that you might obtain. This is because there is a 'lag' between the time you send a request and the arrival of a response from the gateway.

If a single script can line up a hundred requests at once, you might be able to dramatically increase your throughput. PHP is not meant to run as a multi-threaded application, but the [man]curl_multi_init[/man] function allows you to create a very large number of concurrent requests.

Here's an analogy: You currently have four 'assistants' that walk into a store to perform a credit card transaction. Each has to park their car, walk in, choose a product, checkout, and come back to their car. There's an inherent slowness to this process which cannot be sped up. However, if you hire 100 more assistants, then you can dramatically increase the number of products you buy in a given day.

Hope that makes sense.

EDIT: corrected me poor english

Ashley_Sheridan

There are a lot of legal requirements you'll have to meet if you are processing card details on your own server (which you will be if you are retaining the card details for any length of time)

You need to make sure that your server is PCI compliant, which will involve a lot of work. It might be a lot quicker to try and source another payment gateway.