Posted 19th July 2014, responsibly disclosed 19th December 2013.
These 3 issues are still present and unfixed, as confirmed in their form integration v3.00.
Any website that uses SagePay for payment, customers can enter their name as "Craig&Amount=1", and in most cases, SagePay will process the payment of £1.
It's possible for websites to work around this issue, by ensuring that the amount is set before any untrusted data. However SagePay should be encoding the data (e.g. via URL/Percent encoding).
For more information, see "A1.1 The Crypt Field" in their documentation (page 33), where the fields are "separated by & characters".
Version 3 of their API introduced AES/CBC/PCKS encryption, using the password for encryption and the Initialisation Vector.
While I am not aware of any vulnerabilities that allow you to extract the IV from AES, the purpose of the IV is that it should be "random" and different every time, preventing attackers from identifying relationships in the encrypted data, or performing re-play attacks.
This is now confirmed in their updated "A1.1 The Crypt Field" documentation, where I happened to note the use of Hexadecimal rather than Base64 encoding in my feedback.
Once a value has been sent to the SagePay server for a particular transaction code (VendorTxCode), it cannot be changed - this effect can be seen in the first issue.
This allows customers to build up a shopping cart, get to the payment page, click on their browser back button, edit the basket (e.g. add more things), and if the website does not create a new transaction code, the amount to collect will not change.
While not necessarily a security problem, developers integrating with SagePay need to be made aware of this, and need to check the callback and settlement amounts (which I suspect most do not).