One thing you want to keep in mind is that it is a pain in the ass to store credit cards. If you handle credit cards at all, you will have to follow the PCI requirements (available at
https://www.pcisecuritystandards.org/). If you are not storing cards, but just passing them right on to some other entity (a third party checkout service, for instance), things aren't as onerous as they are if you are actually storing cards in your database.
If you are going to accept that card now but not charge it for 4-6 weeks, then it would seem at first that you would have to store the cards. For short delays between receiving a card and charging it, one can do an AUTHORIZE first (which returns a reference number from the gateway/processor), and then later do a CAPTURE to actually get the money. For the CAPTURE you specify the reference number of the AUTHORIZE, rather than give the card number, so you can forget the card as soon as you do the AUTHORIZE.
The problem is that AUTHORIZE transactions time out after something like 30 days. Oops.
Some gateway/processors support doing a new charge on a card that you have previously done a transaction with by giving them the reference number for that transaction. They store the complete information for the original transaction, and copy the relevant fields to your new transaction. Payflow Pro (now part of PayPal) supports this, and pretty much any kind of prior transaction can be used. Thus, you could get away without storing cards using Payflow Pro by doing this:
1. Do a $1 AUTHORIZE.
2. VOID the AUTHORIZE. (So as to not tie up $1 of the customer's credit for a month...although I doubt the customer would actually notice that).
3. When you are read to ship, do a new charge, referencing the AUTHORIZE for the cardholder information.
I thought that all the gateways/processors supported something like this, but in a quick (very quick) check of Authorize.net's documentation I did not find it.
If we were selling physical products, I'd do something like the above to avoid storing cards. However, we sell a subscription service, and so need to be able to re-bill customers. The problem with letting, say, Payflow Pro handle the card storage is that it means we are locked into re-billing through them if that's where we did the initial transaction.
BTW, the reason I say "gateway/processor" in everything above is that even though I've been involved in dealing with our payment handling at work for a few years, I still am unclear on just how the payment industry is actually set up. There are a lot of companies that provide multiple services related to payments (gateway, processor, merchant bank, etc.) that things get muddled, and a lot of writing on the subject mix up the various roles. (I think some of this is on purpose to make people think that they need to get all the parts of payment processing from the same company).