What is the point of paying for a premium solution when there is no support or accountability ? We may just as well switch to a open source solution, at least they have enthusastic and skillful support from their communities.
-
-
An easy way to check if its working is to use set the subnet mask to allow all 256 hosts, then narrow down from there....Originally posted by kev67 View Post
so if your IP is 10.11.12.13 set the subnet mask to 255.255.255.0
(Edit: the IP address is irrelevent in this case and has no bearing on what you set the subnet mask to)
If that works, you may be able to ask sagepay what the specific IP address the transaction came in from (not the user IP but the server address).
edit #2: I've just called Sagepay and they say that that a subnet mask ending in 0 is actually fine. They can tell you the specific IP address of the transaction also. Its worth noting that this may change from your host though, so pinning it down to _the_ specific IP may not be best practice. I'm going to have a chat with our hosts and see whay they say.Comment
-
I have this problem now, getting the message:
"Error initialising payment service. Please try another payment method."
This only seems to be on desktop though. If i try an order on either my iPad or my mobile, i can get through and all is normal.
IP addresses have been added into Sagepay for some time and have also been working fine for some weeks, I've just noticed today for some reason it is no longer working.
Site is hosted with SD, so there can be no compatibility or missing items as the problem. And the site has been working fine for weeks with regular sagepay transactions.
Anyone else having problems or encountered this phenomenon?Comment
-
Originally posted by leehack View Post
I'm not sure Lee, the only thing I can report is that this error message does seem to be generic and isn't specific to one cause only. I'm fairly sure you get this this if you don't have firstname and lastname populated, if your IP isn't registered, and possibly even if the billing country code isn't right. So I guess that it could be any number of things, probably worth checking if both order details on both desktop and mobile are identical to perhaps narrow something down....
Sorry I can't be any further helpComment
-
I had this twice and it was due to IP's not registered, a dodgy upload of my site to my server and the billing code - I was using the typical Isle of Man as a test but didn't use the .PL fix at the time
I don't get the issue Lee is having no more, but it don't really explain why it works on a phone and iPad - it either works or don't work
I'm still sceptical over this Sage V3 interface, I really amComment
-
It looks like as mentioned below that is a generic message meaning an absolute plethora of reasons. It turns out that for example SD checking of an email format is far less stringent than sagepay. So although you can get away with l@l in SD, sagepay do not let you get away with it. So if customer makes a mistake and doesn't realise themselves, they will be stuck there scratching their head wondering what is the problem due to the very unhelpful message.
On one of my examples the post code field had blanked itself, SD was not picking it up as missing and nor were my eyes, so i was trying to go to sagepay with no post code and it wouldn't allow it, but gave no feedback. Having used PCA to put the address in, it wasn't something i'd even consider as i'd put post code in to get the address.
Sagepay also mentioned to me to check the void transactions and i suggest you all do too because on ours at least there were customers suffering the same woe.
As for the debacle on delivery address and some of support saying no problem exists, i spoke to support today and mentioned it and was immediately offered the solution by email. Sagepay integration has been a big worry for a lot of people for a lot of time. To have some support staff unaware of such an important issue and to not have a sticky in the PSP forum about this is plain awful.Comment
-
The following applies to V11 as this is what the client is using and I can confirm that the IP address of the server is correctly entered in MySagePay.....
I have been on the phone to SagePay to ask them about this problem on behalf of a client and we performed a couple of tests while we were speaking.
The problem in this case (and you can see this in the Failed Transaction in the MySagePay control panel) is that the information being sent from SellerDeck to SagePay in ALL of the failures is malformed with a missing 'BillingFirstnames' entry.
The checkout on SellerDeck has a field for Name/Cardholder and this is a required field. SellerDeck seems to try to do something clever(ish) here and so if you fill out this field with 'Joe Bloggs' the information is split into two parts, parsed to SagePay (as BillingFirstname and BillingSurname) and all is well and the transaction will continue to payment. However, if the customer were to only input 'Bloggs' the transaction will not continue because SellerDeck cannot separate this into two pieces of information.
Also, whilst on the phone, my colleague tried a test and put her name in as 'L S Smith' and continued through to SagePay. At the point where you choose a card type, she cancelled so that the guy at SagePay could see where the problem was. SellerDeck had then split the 'L' and the 'S' into firstname and surname and added 'Smith' as the first line of the address (ie moving it 'down one' field)! This is VERY confusing for the customer where it is entirely likely that they will type into this field exactly what is printed on their credit card, thinking that this is the correct information where, in fact, it is not!
Clearly this should be an ultra simple solution on the part of SellerDeck. Why not have two input fields for the cardholders name. First Name & Surname (possibly a third non required field for middle name/initial to make the customer feel more secure in that they have typed in everything on their card)??. Make these both required fields and parse them through as completely separate pieces of information.
At the stage where the customer fills the form out on the SellerDeck checkout, these entries don't even have to make sense (ie you could enter First Name: ABC, Surname: XYZ), the textual input is irrelevant here (and can be nonsense as long as there is something in the box) but it has to be entered correctly on the SagePay form, where it is editable anyway, at the payment stage in order to make the transaction a successful one.
The upshot of all of this is that the failures were probably due to 'Customer Error' although the customer is not actually to blame!
It took me 15 mins on the phone to an extremely helpful support guy at SagePay to identify this problem. Why should this be down to me to find these issues, surely SellerDeck are just as capable of making that call??!! I am neither the site owner, nor the software developer, but I managed to get this information from SagePay.
It is now really up to SellerDeck to make their checkout form compatible with the information required by SagePay. I cannot do anymore as this is deep within the Perl scripts that power SellerDeck and I wouldn't even know where to start to look for this, let alone have the time to rewrite and test them!
I hope that this helps out all involved....Comment
-
Perfect! Thanks Peblaco. It's certainly not obvious though.
Cheers,
DuncanComment
Comment