bhtloan, you've hit a couple of those areas where the PCI materials are vague and/or ambiguous. (Often deliberately vague & ambiguous; the payment counsel is as much a political institution as any other one that takes on topics of high importance to millions of people & entities, a lot of them with diverse and frequently-conflicting interests.). I'll just give you my read of where I think the opinion of the mass of PCI compliance interpreters is (for the "storage" question ) and where the guidance points (for "e-commerce" question.)
-On what "storage" means, I think it's fair to say that generally the practical line is drawn hereis this: is information held entirely in RAM vs. is it ever written to a drive (or other non-volatile storage medium). Now, in terms of application of those ideas, most cases are actually quite clear. If credit card info is held in a POS machine's RAM for a split second to encrypt it and address it and then sent on its way, that case is (almost) universally held not to constitute storage. At the other end of the spectrum, if cardholder data is written to a drive in order to keep should a customer want to buy something from you at some point in the indefinite future, that scenario would (almost) universally be regarded as storage, such that the data needs to be encrypted and you need SAQ D. The in-between is where things can get a little harder...
In practical terms, I would say that in almost any scenario where cardholder data is written to a non-volatile medium--like a hard drive, an SSD, or magentic tape--rather than RAM I'd advise a client that it was their responsibility to encrypt. Simply because even though it may be your intent to quickly delete said information (within minutes or hours, say), it physically can persist for a much longer time if you neglect to do what you intend. In contrast, the contents of RAM quickly vanish whenever a machine is rebooted or turned off, and thus--in theory-- info written merely in RAM gives an attacker a much, much shorter window to steal it. Thus, it is considered outside the policy purpose of not having in-the-clear info vulnerable to theft for any long period of time. (Alas, as we've seen with the endless data breaches of major retailers over the last few years even that short window is still far too long to prevent malware from grabbing cardholder data.) Now if you specifically pursue a policy of rebooting and powering off servers as rarely as possible so that data will be in RAM as long as possible, at that point are you "storing" it? Possibly. But I think the validity of the general rule/s stands.
To sum the topic of storage up: find out if anywhere in the process from where cardholder data enters your systems to the point it leaves your systems the data is written to, well, storage. If it stays wholly in RAM and gets discarded in a seconds, a few minutes, even a few hours you are very likely okay for SAQ C. If it is written to storage, you likely need to follow the rules on encryption or tokenization and go with SAQ D. Even if you write it to storage for some purposes besides using it future authorizations and have a highly-reliable software mechanism in place that makes sure it gets wiped in seconds, minutes, or hours...well, I'd follow the encryption/tokenization standards and use SAQ D to be on the safe side. But there might be some dissent among PCI interpreters about whether you or not you have really engaged in storage.
--Now, on the "e-commerce point", this are actually somewhat more clear cut. Not because the text of the SAQ rules/guidance itself is clear. (One part says "ecommerce channels" can't use SAQ C, but another part just above that one specifically contemplates that "e-commerce....merchants" can use it. Huh??.) However, while the text is oddly written there's a chart in the same guidance that seems to be unambiguous. The chart is on page 18 of the pdf, but let me blow-up the relevant part:
I think the "E-commerce Transactions" flow is pretty decisive: SAQ D is the only route you have. So regardless of how the storage issue turns out, the answer certainly seems to be SAQ D. To me, anyway. (Standard disclaimer: Remember, as far as you know I'm just some guy on the Internet...)
All of the above being said, your QSA is the guy or gal who is directly familiar with your situation, qualified to advise you on PCI, and professionally responsible for doing so. When in doubt, lean on his or her advice. (Which is also that you should use SAQ D, anyway. )
Hopes this helps. Cheers.