Possibly SAQ C, but be careful, because SAQ D is full of people who thought they were SAQ C. If you gave more information, it might not be long until I nodded sagely and said "ah, yes, SAQ D."
If you haven't, you should read the PCI DSS Self Assessment Questionnaire Instructions and Guidelines.
You're not SAQ A. A is for "Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced." (emphasis mine). If your server is accepting a card number, then re-transmitting it to your processor, then you're transmitting card data, which is a cardholder data function.
You're not SAQ B. B is for "Imprint-only merchants", that is, merchants with access to the physical card. "B" is for Brick & mortar :).
You're not SAQ C-VT. VT means "web-based virtual terminals", which means that your employee sits with a computer in front of them and a phone and types in the card numbers the customer tells them; the VT acts exactly like the terminal in the checkout line at your supermarket: talks to the processor, gets back a response, doesn't store card data. If customers are entering data into your web server, then it's not a VT.
You might be SAQ C. If you're immediately sending auth requests off to your processor, never storing them (like for batch), and don't have any other systems talking to the system that's taking cards, then you might qualify for C. But the kicker is "The payment application system/Internet device is not connected to any other systems within your environment". You really have to be as minimal a conduit as can be. This is where the nuance about transmitting-but-not-storing can impact you, by the way. Storing card data will push you up to D, just transmitting might not - if properly limited.
That leaves you with SAQ D, "All other merchants not included in descriptions for SAQ types A through C". It's the longest SAQ, which is why a lot of borderline cases believe hard enough that they become a SAQ C.
But even if you're SAQ D, if your processor supports tokenization, you can reduce your scope by answering "N/A" to a lot of questions and listing that as your compensating control. For example, DSS 3.4, the requirement to encrypt card numbers, can be marked N/A if you're never storing card numbers but instead using tokens.
I work for Litle, but you might look into their PayPage + Vault,
which gives you tokenization and allows you to avoid having card
data transit your server. Recurring payments, too, IIRC.