The PCI DSS applies to any system which stores, processes or transmits cardholder data. In the scenario you describe above, to the letter of the law, you would need to apply the standard to all systems and networks which make up Site B.
As you are not storing cardholder data in Site B this will at least reduce the amount of work you would need to cover as, for example, as far as I can see, the whole of "Requirement 3 - Protect stored cardholder data" would be N/A.
You will however need to ensure that things like your firewall/DMZ architecture is appropriately put together and managed (Requirement 1), that cardholder data is encrypted in transmission if the connection between Site A and Site B is over an "open, public network" like the Internet.
Picking up your point, and to echo @Rook, SSL will be fine for this purpose (see Requirement 4.1). You do not need to hash or encrypt the card data at this point. It is only when it is at rest.
Moving through the standard, pretty much everything else will apply, Systems should be hardened (Requirement 2), Anti-virus (if it's a system "commonly affected by viruses") and patch management (Requirement 5), good Software Development processes (Requirement 6) - not forgetting the legendary 6.6, code review or WAF.
Strong access controls (Requirements 7 and 8), Physical security (9), Logging and monitoring (10), regular testing (11) and good information security management (12) will all apply as far as I can see.
Without any of these elements if I were the attacker I would simply target Site B and grab the data either straight off the server as it's input by the customer or as it transmits out of Site B into Site A.
This is actually a common scenario in the payment processing world (think PayPal, WorldPay, etc). "Merchants" (someone taking credit card payments) typically have two choices when they wish to integrate with a payment processor to take credit card payments.
1) They receive the card data themselves, typically through a web form and then POST that data to the payment processor's API for authorisation, etc. This is typically done by the larger merchants. They process the response and update their systems and respond to the customer appropriately.
2) They "redirect" the customer to the payment processor who then takes the card data through a form on their own website so the merchant never sees the card data at all. The merchant is typically then updated as the success of the order by some "out of band" HTTP POST to the merchant's website. The customer obviously has an immediate on screen result.
In option 1, the merchant would be required to achieve full PCI DSS compliance. In option 2 the merchant does not have a need to comply as they are not storing, processing or transmitting card data.
If Site B is not currently in scope of your PCI DSS compliance and you wish to keep it that way, I would suggest you develop a means to take the payment data directly on Site A and Site B just points people that way.
I hope this was useful. I've got a lot of experience with the PCI DSS so would be happy to discuss further. Standard disclaimer though, I'm not a QSA so any decisions regarding scope should be verified with a Qualified Security Assessor before beginning work.
