This question might be suitable for serverfault.com instead. But as it's related to development I'll try to answer it to the best of my ability:
When the connection is not carried over SSL (or any other security measure), the traffic is interceptable and malleable. This means that you can not trust that the data you are getting is actually from the user, unaltered. Additionaly, the user cannot trust that he is in fact talking to your server directly without someone in the middle snooping or altering the data.
Seeing as the payment system is a separate system that does allow for SSL, then you have the most obvious security issue covered. It is then up to you to evaluate whether anything up to that point can be considered sensitive. (for example username and password, if the store requires a login).
A good rule of thumb is that "Anything not encrypted is potentially known by anyone. In addition it is also alterable." Say a user wants to place an order, and clicks the appropriate buttons and links to get to the payment system. Now, if a MITM attacker wants to snoop the credit card details, he can intercept the traffic and substitute the buttons and link to trick the user to his own system, made to look like yours, with the only purpose of gathering credit card details. Attacks like this are possible because the average user doesn't know or care about the danger of accepting certificates from untrusted sources, and it is hard to combat unless awareness is raised around the issue. I have seen online shops display a warning before accessing the payment system that the user needs to verify that the certificate actually stems from their server, and that the URL is still refers to their webshop.
...But i digress. To sum up: You've got the important part secure. As for the rest, there are some pitfalls, but manageable if handled properly.