Assuming I decide to use payment gateway and not to use their hosted page, but rather provide my own credit card details form, and then send data to their backend via xml as explained on this page. Then:
Thanks for any help
1) If you're handling credit card information at any time you need to be PCI compliant. You need to sort out coding issues, your host needs to deal with any hardware and software issues with the server, and the payment gateway company has a lot of issues to handle (which is a list too long to list here but you don't need to worry about anyway).
2) No. SSL will help you be PCI compliant but there is more to PCI compliance then how the data is transmitted from the user to the server. What you do with that data and how you do it also come into play. For example, if you are storing credit card information you'll need to be using encryption and not storing values barred from storage by PCI (i.e. CVV numbers). Putting this information in a session counts as storage.
One aspect that hasn't surfaced in the other comments is that PCI-DSS is assessed against an implemented, operational system and that the most significant component in that system is human processes and controls. The premise behind "my site would be automatically compliant" includes an assumption it is possible to assess a piece of technology, taken out of context, against the PCI-DSS.
Any custom application cannot, by definition of the PCI-DSS and PA-DSS, ever be declared PCI-compliant on its own merit. Applications and hardware that are non-customizable, turnkey solutions can be assessed against the PA-DSS but even they cannot be certified as PCI compliant out of the context of an implemented system and the human controls and processes associated with it.
Requirements 2, 10, 11 and 12 are entirely concerned with system controls that are external to your application and representative of human procedures and tasks. Of the other requirements, a close look at each reveals that they either directly or indirectly impose constraints on the human processes and controls.
So definitely read and absorb the other advice concerning the technical requirements of PCI but give up the notion that your finished application can ever be declared PCI compliant outside the context of a working, implemented system. A better approach would be to consider those requirements which are not directly related to technical details of your app design and ask yourself how the app helps the customer meet those requirements. For example, does your app make it easy for the customer to "Track and monitor all access to network resources and cardholder data"? (Requirement 10)
Many application vendors take the position that requirement 12, "Maintain a policy that addresses information security for all personnel," doesn't apply to them at all. But customers often come back and ask pointy questions about whether the app helps or hurts them on this assessment item. The customer is responsible for training their staff on how to prevent, detect and recover from a breach and the capabilities of the application to interoperate with security scanners, backup of configuration and data or to restore to a prior point in time are all critical. PCI requires vendor-issued security-relevant patches to be applied within 90 days or less so customers will want to know how and where you notify them of these things, how easy or disruptive it is to apply patches, whether the app must go down to apply them, etc.
Hopefully, a reasonably detailed assessment will cull out all the apps with obvious technical errors like failing to use TLS encryption, rendering login pages over HTTP or recovering passwords rather than sending a reset link. Any aspiration to comply with just the technical aspects of the PCI guidelines merely allow a new app to rise to the level of a commodity. To differentiate the app in the marketplace, design it to help the customer meet the PCI requirements that are not the direct responsibility of the app.
I helped create the Drupal PCI Compliance white paper, which provides answers to these and a host of other questions that you may have when trying to make your site compliant. While you may not be using Drupal, the principles covered within this document are high level and easily apply to wordpress, Joomla, or any other eCommerce CMS.
Answer to question 1: Yes you should be worried about PCI compliance all the more.
Answer to question 2: Using SSL form to gather the Credit card information takes care of secure transmission of data from the client to your server. So that is sufficient if you don't plan on store the credit card data on your servers. If you want to store the credit card data then you need to comply with PCI DSS for storage of credit card data.
