Regarding Form integration - Sage Pay cannot guarantee to return the customer to your website. If the customer closes their browser mid way through a transaction or if something goes wrong with the redirect stages, it recommended within our protocol guides to check the status of the transactions. In normal circumstances however whete the customer does not close their browser and there are no redirection problems, Sage Pay will return the customer to your sire, either to the SuccessURL or FailureURL.
The SuccessURL will be appended to the field called Crypt. The SuccessURL and FailureURL should point to scripts on your server that extract the information in the crypt field and use it to update your database and/or format an appropriate response page for the customer. You may choose to direcet your customer to a static HTML page that ignores the contents of the crypt field. In such cases, you will need to nmanually check the My Sage Pay report pages to determine if a trasaction succeeded or failed.
This may be relevant because of the cart/stores interaction but ignore this for a second..
Regarding Server integration - the problem you encounter appears to be after Sage Pay send via the Notification URL the status of the transaction along with the other fields detail such as the VPSSignature. At this point Sage Pay require a handshake from you to acknowledge receipt of the Notification post. Within the acknowledgement you confirm the status, the RedirectURL and the StatusDetail.
Right... So basically SagePay require an extra confirmation "handshake" with the shops server to confirm that the payment status has been received and the order updated. Is that correct?
If so, that's one extra step than say Paypoint.net or most other gateways from what I remember and is divorced completely from the "Success/Fail" page discussed above and earlier in this thread.*
It's important to understand that there's two levels of transaction going on here.
The Server to Server communication between the store and Sagepay, and then the customer to store communication.
My guess is that the store itself is the problem as it appears to have tied that last "Success" page into the final confirmation to Sagepay that "
all is well" with the order and acknowledges the payment status. If that's true, it's a bit of a poor integration that needs addressing.
If the customer doesn't return to the store
(perhaps thinking they've paid so that's it) then the last part of the transaction doesn't complete and Sagepay cancels the order while the store is not setup to recognise the reversal and you end up with the mess described by the OP.
While Sagepay could perhaps clarify this a bit better it's really whoever wrote the integration for the store that needs to ante up and sort it out so that regardless of the customers interaction with the store after completing a payment, the transaction is still acknowledged and updated properly.
In that respect it's really down to the store coders and/or the associated payment/checkout module to fix it so I would actually be getting on to their case rather than SagePay.
If you're able to supply a TxID or vendor name and TxCode to our Support team, we may be able to check the logs for a transaction that did not reach the desired location and may be able to provide more information as to why.
I would definitely take up this offer (if you haven't already) and figure out what's going on and confirm whether my guess above is accurate or whether the issue is more ingrained elsewhere.
Beyond that it would incredibly useful to others reading this thread to know what cart system you're using so any other affected users can check their logs as well as being forewarned.
And one small nugget of feedback for Sagepay Support... Please spellcheck your responses. The level of mistakes in your response made me seriously question if you were a legit rep' from Sagepay.
*Footnote: I can well appreciate that the extra confirmation step could be seen as a pain in the backside and why's it there, blah, blah, blah but perhaps a concrete example of why it's useful.
With Paypoint.net, occasionally I get a payment confirmation where the store server falls over, hits a high load, exchange rates change (between order confirmation and payment completion) or any number of rare but fatal events from the point of view of the validation routine. To date I've counted five instances from an average of 1,000 transactions in a given 6 month period so having something that were to catch and resolve such an event would actually be very handy.
Hope that clarifies what's potentially going on... As much because it may highlight the store code is not fit for purpose with other gateways as well. Not a fun thought.
