SAGEPAY Invoice and Delivery Field Corruption?

[leehack]

When i put a sale through our site where the invoice and delivery address are different, i note that SD retains the correct addresses but it looks like Sagepay is being sent the wrong address info for the delivery address. This was picked up because of a fraud check, but essentially it looks like a difficult thing to spot as the customer has to spot it because the details in SD remain correct and obviously are what we work from.

To clarify. I put my address in as invoice address on SD, i put my mates address in as delivery address and these details remain correct within SD. BUT, when i get my sagepay confirmation page, both invoice and delivery address show the exact same address, APART from post code. Sagepay gets the invoice address plus the delivery post code as the complete delivery address.

This has implications on fraud checking.

Anyone else had this or perhaps suffering it without knowing? It looks to me like the integration is sending over the 'invoice' address fields for both the invoice and delivery fields. Apart from on the postcode where it does that correct. I have the exact same address showing on the sagepay confirmation page (apart from post code) despite having put 2 different addresses in and SD having these correct details in the order.

[leehack]

I've just tried this on our second site and it's the same problem. I have also checked within the software and each of the fields has their own ID, so there appears to be no corruption on field IDs within SD.

If someone running sagepay can do the same on their site, we will have a confirmed bug, because this is currently until confirmed by anyone else only have an issue on both our sites which are run from same software etc.

You don't need to complete payment, once you put your card details in and go to the confirmation page, expand both the invoice and delivery addresses and you should see the fault.

[leehack]

CONFIRMED BUG.

I've just tried it on a random SD site that had Sagepay and the same thing happened. So it looks like an integration issue for sure now.

Next stage is play 'admit the bug' tennis with SD and Sagepay and see who takes the responsibility.

I'm on latest version on Business 2013 and have the new sagepay checkout with the responsive sagepay checkout.

YOURS will have this bug too, so check it out please!

[watsy]

We sent support a snapshot with this 3 days ago - thought it might just be our bespoke site... obviously not, thanks Lee.

[leehack]

Have you got a support ticket number watsy? we need to have them accept its real and across the platform first i guess and then who's mistake it is.

[leehack]

Just to clarify:

Delivery Name and Post Code are going across as they should do, its the remaining address fields that are not. Address1-5 etc.

[Mike Hughes]

Interesting.

I'm on latest version on Business 2013 and have the new sagepay checkout with the responsive sagepay checkout.

If I remember correctly, I heard it mentioned at the conference that the latest version of the integration had been developed by Sagepay whereas sellerdeck had written the previous versions themselves.

It might not help, but might explain where the problem came from and why it hasn't been raised earlier.

[watsy]

The Support ref is 77488

[brian.mc]

We're having the same problem. Tried placing a test order, and at the payment confirmation page in Sagepay, it's showing correct name and country for delivery address, but the rest of the address is showing as the customer's address. We've had several abandoned carts due to this - some customers phone us about it but others are simply going elsewhere. Even when they call us and we explain the problem, they view it as unprofessional and lose trust in the site, so it needs to be fixed asap. Problem has only started since we upgraded to Sagepay Protocol v3.

[peblaco]

I heard from SellerDeck Support that is a known bug and there is a simple fix. The bug reference is PSP-544 "Delivery address uses invoice address for part of the address". It applies to all recent patches where SagePay v3 was added - 11.0.6, 12.0.6 and 14.0.3. The new SagePay Perl script has incorrect fields in the delivery area. Fix from SellerDeck Support below. After applying the fix a Web menu > Refresh should re-upload the script. Edit "OCCSagePay.pl" in "CommonOCC" folder under the site folder replace the following 3 lines (they occur in 2 places)

$hashParams{'DeliveryAddress1'} = $::InvoiceContact{ADDRESS1};
$hashParams{'DeliveryAddress2'} = $::InvoiceContact{ADDRESS2};
$hashParams{'DeliveryCity'} = $::InvoiceContact{ADDRESS3};

With

$hashParams{'DeliveryAddress1'} = $::OCCShipData{ADDRESS1};
$hashParams{'DeliveryAddress2'} = $::OCCShipData{ADDRESS2};
$hashParams{'DeliveryCity'} = $::OCCShipData{ADDRESS3};

[leehack]

Thanks Louise.

I cannot believe this is a known bug and they've done nothing to relay this to users. Good grief, i'm almost speechless that they are still making these mistakes. Keep it quiet and hope very few find out until we fix it, was a fantastic tactic in the 1980s.

Wasted half a day on this. Incompetent at best. Should be a bloody sticky in the PSP forum as a minimum!

I saw one of them read this post this morning!

[saucysal]

I too am flabergasted

We have been having problems with this without knowing there was a bug. Thanks to forum users for finding this and Louise for fix.

Sarah

[kev67]

Yep, I'm getting the same thing as well. All is correct within SD on the computer as is the auto order email that is sent to me and the customer, but in Sage the only change is the delivery postcode

Good job there's no auto payment confirmations being sent out as the customer would be confused and call your site "A load of ***p"

[grant]

A client of ours is having exactly the same issue running V11

Sellerdeck support have said "I have checked with my colleagues and also looked on the internal support area and the community forum, there does not seem to be any similar reports or incidents. "

I shall direct them at this thread.......

[kev67]

errrrr......................Peblaco (Louise) has confirmed it above that it is a known bug and she is always on to SD and on here to help

She should be paid to be on here in my opinion because I haven't seen any updates on the main 'SELLERDECK NEWS' thread

SD, listen to your customers will you....