What HTTPS does, and -all- that HTTPS does, is stop 3rd parties from getting involved in the middle. It stops man in the middle attacks, 3rd parties reading or changing the data as it is transmitted, and that is it. (Edit, since I can't comment on another post: You are still vulnerable to proxies that the end user trusts. https keeps an -unknown- 3rd party from -silently- pretending to be you, but your user can still collaborate with a known proxy. He'll get warnings indicating that a man in the middle attack is happening, and he can choose to disregard those and permit it because he's the one controlling said attack. Demonstrate to yourself easily by setting up Fiddler and telling it to proxy https connections (not the default, and it warns against it, but it will do it for you if you tell it to. ))
So you have two main potential points of problem: Either end of the connection. You could have a problem in your server code, or a problem with a malicious client (not necessarily the current user) (A 3rd class of problems is possible if you bounce between http and https at any point after authenticating the user or giving them a 'session', session hijacking or sidejacking - 3rd party gets enough information during the http part of the conversation to initiate their own authenticated https conversation. "Firesheep" is a tool for demonstrating this.)
The best overview I've seen for keeping up to date on what you need to know is the Open Web Application Security Project top 10 list. 
On the server side, you need to make sure your code is checking for malicious input:
"Sql Injection" ("little bobby tables": ) (chiefly defended against by consistently using "bind variables", but see OWASP for more)
For your credit card processor scenario, is generally a fine idea because they deal with security and you don't need to worry about storing card numbers. What you need to do is secure the data being sent to them. You could do this either by
Talking to the processor directly from your server instead of redirecting the user to their site. Has its own set of trust and security problems, your users have to be willing to give you their credit card info and believe you when you say you won't screw it up. Requiring users to trust you might reduce sales, might be not worth it so don't necessarily insist on this option.
Maintaining a product catalog with the processor so they know your pricing.
Signing any pricing information you send the processor so that it can't be tampered with.
Checking back with the processor after the customer has entered their data to make sure it's right.
Unfortunately, it looks like it's actually par for the course for the processors not to support product catalogs or signing prices. For example, I don't see it as an option with Paypal "Website Payments Standard" . The only answer in those cases is a post-processing reconciliation step - check the amount paypal says you got against your order data saying how much the amount should be, and cancel any order where it's wrong. This is a bad option because needing to re-contact the user is expensive and time consuming, and you'll be getting into arguments where people lie and blame your system (and sometimes they might not even be lying - bugs are possible.)
Example of option 4, Paypal Express Checkout has a verify step: you're supposed to directly call 'GetExpressCheckoutDetails' before 'DoExpressCheckoutPayment' to do a confirmation page.  So I'd push for something like that - user enters payment info on a 3rd party site, then you contact the site directly from your server and verify the information for the user's confirmation page.
(As a new user here, I'm limited to 2 hyperlinks.)
 OWASP top 10 list: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
 Little Bobby Tables SQL Injection: xkcd.com/327/
 Charles rewrite proxy: www.charlesproxy.com/documentation/tools/rewrite/
 Paypal 'Website Payments Standard' variables, note lack of signing options: merchant.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_html_Appx_websitestandard_htmlvariables
Then look at 'how it works' tab and note lack of 'they go back to your site for confirmation' step: merchant.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=merchant/wp_standard
 Paypal express checkout (see diagram where -your server- talks directly to paypal for confirmation page info): https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_WPECIntegration
 Fiddler's page on HTTPS: http://www.fiddler2.com/fiddler/help/httpsdecryption.asp