Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

I'm trying to setup a basic system on my site to accept credit cards for delayed processing. What I will be doing is collecting a bunch of orders/credit cards for a group of people, then after a certain period I will need to process those cards and make the charge.

This is so that a group of people can individually place their order knowing that their card will be processed in X number of days once everyone has placed their order from the group.

My question is what would be the best way to go about doing this? I want to ensure I am accepting Visa/Master Card/American Express and possibly Discover Card. Also, with this system would it be possible to accept Pay Pal information so that I could then process that instead of a credit card for their Pay Pal account?

Also, what is the best way to store these credit cards. Obviously a secure DB and a page that uses SSL for submitting their order, but what all do I need to accept? Obviously card number, CVV, Expiration Month, Expiration Year, can this all be normalized in a database. And what would you recommend for encrypting/decrypting these cards? I will need to decrypt them for processing later on.

Any advice on any of my questions would be great.

share|improve this question
add comment

4 Answers

Avoid storing credit card data if at all possible. There are a whole load of legal issues surrounding it (e.g. there is almost no situation in which you can store the CVV), and you open yourself up to liability if your site ever gets hacked.

If you have to go down this route, to start with you should familiarise yourself with PCI DSS, which is the standard for storing card data (and a legal requirement here in the UK at least). You will also need to check with your host to ensure they are PCI compliant (i.e. they have the necessary levels of physical security protecting the servers where this data will be stored).

Some payment gateways offer a kind of authorise-now-pay-later feature, where you submit the card details and amount to them and they send back a unique token that you can safely store. You then resubmit this token at a later date if and when you want to perform the transaction. This way you can still offer your delayed payment but without having to store any sensitive data yourself, so this is what I'd recommend looking into.

Edit: I believe Authorize.net is a big US gateway - with their 'Advanced Integration' API they have an Authorization only mode which does what I describe above, although the token only lasts for a maximum of 30 days. So perhaps this might work for you.

share|improve this answer
    
Tim - Thanks for the great response. I definitely will be need the delayed processing feature. Any other resources that you might recommend beside Authorize.net that I should look into? It looks like they may be very close to what I need. –  aherrick Sep 29 '10 at 22:32
    
I'm not too familiar with the popular gateways in the US but I'm sure there are others. All I can suggest is get in touch with them - I'm sure your situation isn't unique and it's in their interest to find a solution that will work for you. –  Tim Fountain Sep 30 '10 at 0:01
add comment

The short answer on storing credit card details: DON'T

See http://webmasters.stackexchange.com/questions/1017/storing-credit-card-details for a good discussion.

share|improve this answer
    
JMB Thanks for the link –  aherrick Sep 29 '10 at 22:32
add comment

Here's the problem with doing something like this. You can't charge the person's card up front...so you <> hold onto it...maybe by an authorization, maybe via using a card company to do a save, but definitely not on your own server....anyways, the person goes to finalize the purchase days later and just happened to buy a new PC, which wipes their credit limit down to $5. Now what? They're $95 short of a hypothetical $100 purchase that the system allowed them to make several days ago. Not a good UI event.

My company deals with re-bills on a daily basis. They stink. Both from a programming side of things and customer service standpoint. I can't tell you how many times we've heard "I didn't authorize that..." Oh, but the fine print says you did!

PayPal could work for this delayed method. But from so many different points of view, I wouldn't touch a delayed transaction with a payment processor like PayFlow.

share|improve this answer
1  
Thanks for the feedback! So what you're saying is I couldn't just store the CC info on lets say Authorize.NET servers. Then in 2 weeks come back and try to process them all for the amount they agreed to upon submitting their card information? Also you mention PayPal perhaps working. How would they be advantageous over say Authorize.NET? –  aherrick Sep 29 '10 at 22:45
    
Well, you could with Auth.net...but again, there's no way to guarantee that the authorization will be valid in 5 days. There in lies the problem. I supposed paypal could be in a similar boat, but perhaps less so since they allow you to carry a positive balance in addtion to other paid methods. Having just gotten through a big site that used paypal, be forwarned...there's all sorts of hidden voodoo as you get complicated. Best to use PayFlow if you're going to be doing any more than basic transactions. –  bpeterson76 Sep 29 '10 at 22:54
    
Do the authorisations not reserve the funds (without charging the customer)? Perhaps that is optional. –  Tim Fountain Sep 30 '10 at 0:03
add comment

Use a service like Authorize.Net's Customer Information Manager. It is designed to do exactly what you want. It stores the credit card information for you as a customer profile. You then refer to that profile to make future purchases without needing the customer's credit card information again.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.