I presume you're talking about the different integration methods.
There are two integrations you ought to care about.
Sage Pay Direct - The card information is collected by your site, and transmitted directly to Sage Pay. Unfortunately with this integration method you need to care a lot about PCI DSS compliance. Since your server sees the card, you'll fall under a much higher level of PCI compliance. Depending on your transaction volumes, you'll need to complete a SAQ D - this is a very long questionnaire that asks about your network topography, access to server rooms, wifi networks, security and encryption, etc. It's no small undertaking to become compliant at this level. Many merchant banks will insist on PCI DSS compliance.
The plus side is your customer never leaves your site, and get a nice, integrated experience.
Sage Pay Server (Redirect) - This is where your customer will be sent to Sage Pay to take the payment. Your server will never see the credit card details, and therefore you fall into a much lower level of PCI DSS compliance. The sting is your sales journey looks disjointed. It's slightly more painful to set up, as there is much server to server communication between your server and Sage Pay. But it works well.
Sage Pay Server (In frame) - You can run Sage Pay in your site, so it appears to your site like you are taking the payment on your own page. You'll probably need to run under SSL though.
There is also Sage Pay Forms integration, which is similar to Server.
We offer a plugin that offers integration with both Direct and Server, so you'll have the opportunity to use either, depending on your own needs and stomach for PCI DSS.