Sellerdeck / Sagepay no longer sending confirmation emails follwing V3 upgrade

[grant]

Hi All,

We have a client that is using Sellerdeck version 11.06 - just done the update for the Sagepay V3 etc.

After some teething issues it is working now and payments are being taken etc.

But - the customers are no longer getting an email confirmation of the order.

Sagepay say that that is correct, as it is impossible for them do send the confirmation email as they used to because of something to do with the way Sellerdeck interacts with them.

Ok....

But surely Sellerdeck should then be sending a confirmation email?

Either of these systems must send a confirmation email, it is a must.

Any help in getting this sorted out would be most appreciated.

Cheers

Grant

[grant]

Hi All,

OK, have now read the note about Sagepay not being able to send emails anymore.

But "Order confirmation emails from SellerDeck will be sent as normal."

Any clue as to why this bit is not working?

[PA.com]

Hi Grant

I've been getting this problem as well, and in my case I'm 99% sure it's a problem with digital downloads. All of my products include DD links and the confirmation emails have not been arriving since upgrading to SagePay V3 (I'm on Sellerdeck 12.0.6 however).

To prove this, I added a new product without download links, ordered it though SagePay and the order confirmation email was sent properly. I then ordered the same product but this time alongside a DD product and... no email.

Is your client's site one that uses digital downloads, I'd be interested to know?

Paul

[grant]

Hi Paul,

I read your post about this, but unfortunately, this client is not selling digital downloads, so created a new thread

[PA.com]

Okay Grant, sorry that wasn't the answer.

Just to check though, even if they're not directly selling downloads, might they for instance be selling electronic items but including the instruction manual as a free extra to download after the order? Basically if there's anything in the digital download tab for the product then the order email isn't sent.

Other than that, are the customer emails set up as HTML or text-only. This is the only other thing I can think of at this time. Mine are set up as text-only, and work as long as no download links are included (which are set up as http:// links). I've never used HTML customer emails as they don't work for the links, so I don't know if this makes any difference.

[grant]

Hi Paul,

I am sure that this client is not including any element of digital download.

Interesting point about the nonhtml / html email. Where is that set ?

Cheers

[PA.com]

That is set by selecting 'Customer Email' where it says Select Page Type, and that gives you a choice of HTML or text only.
I can't quite remember if I had to set this up manually by using the Design/Library/Layouts/Email Inner & Outer Layout menu options.

Select Page Type is next to Split View/Design View/Code View by the way.
I say all this using v12 but I would imagine v11 is the same...?

I have been asked to report this problem to Sellerdeck support, and have done so referencing your post as well. So I'll let you know if and when I get a response from technical support. It's reassuring to know Sellerdeck want to get on the case, well done guys!

[grant]

Hi Paul,

Ah, very many thanks on mentioning our issue as well!!

Here is hoping something can get resolved soon!

Cheers

Grant

[NWTDAXS]

V3 integration

Have just upgraded to v3 -- with the loss of payment confirmation emails.
Order confirmations still arrive -- but with no indication of the payment method chosen -- and more importantly, whether or not successful if paid by card.

I occasionally need to process orders / work out of the office -- so unless SellerDeck plans to support downloading orders to a smartphone / tablet -- then short of logging-in to Sage Pay to check status of a particular transaction, it's somewhat a backward step.

I'm surprised there hasn't been more discussion on this -- or am I alone in seeing this as an issue. Difficulties of working out of office aside, surely customers expect payment confirmations from an on-line purchase?

Does anyone know a solution to this?

[Buzby]

I think I'm going to throw the towel in with Sagepay after 11 years and move to another company.

Not too confident on this IP address system, and lack of emails to us and the customer.

V3 = more chances of the integration breaking, and more customers contacting us as receipts not arrived.

Backward step in ecommerce

[kev67]

Have just upgraded to v3 -- with the loss of payment confirmation emails.
Order confirmations still arrive -- but with no indication of the payment method chosen -- and more importantly, whether or not successful if paid by card.

I occasionally need to process orders / work out of the office -- so unless SellerDeck plans to support downloading orders to a smartphone / tablet -- then short of logging-in to Sage Pay to check status of a particular transaction, it's somewhat a backward step.

I'm surprised there hasn't been more discussion on this -- or am I alone in seeing this as an issue. Difficulties of working out of office aside, surely customers expect payment confirmations from an on-line purchase?

Does anyone know a solution to this?

Just wanted to say that you're not alone on this and it is a pain in a**e, utter useless that you have to loggin every time to see if a payment has gone through

[kev67]

I think I'm going to throw the towel in with Sagepay after 11 years and move to another company.

Not too confident on this IP address system, and lack of emails to us and the customer.

V3 = more chances of the integration breaking, and more customers contacting us as receipts not arrived.

Backward step in ecommerce

Same here Jason, although I've had to revert back to V.23 & V14.02 as I just get a 500 error when I press the 'proceed button' in Sagepay

[NWTDAXS]

V3 lack of payment confirmation

.... according to Sage, the reason there are now no payment confirmation emails produced is that SD has chosen to implement V3 via SERVER/ Direct integration rather than FORM (not being phased out) for some reason.
Does anyone know what the benefit of this is to us -- and why can't both types of integration be offered?

[malbro]

.... according to Sage, the reason there are now no payment confirmation emails produced is that SD has chosen to implement V3 via SERVER/ Direct integration rather than FORM (not being phased out) for some reason.
Does anyone know what the benefit of this is to us -- and why can't both types of integration be offered?

I did look at using the Sage SERVER API with Sellerdeck 2013 but at the time the Sellerdeck implementation was the FORM API, which cannot be mixed with the SERVER API, even though there was Sage documentation that said it could.

The SERVER API integration is a more powerful system that includes the ability to handle taking payments that do not exactly match the value on the order, and also reserving the payment at the point of order and then taking the payment at shipping. For example for users who supply goods by weight they can take the correct value for the weight supplied rather than the aproximate value on the purchase order, there is an upper limit above which you need to refer to the customer, if I recall correctly it is 10% above the value on the order.

It is not a Sellerdeck decision to only use SERVER API, AFAIK Sage only allow one API to be implemented in your PSP software, you cannot mix them and SERVER API provides better features overall.

The email to customers should be handled within the Sellerdeck package as the SERVER API will provide Sellerdeck with the necessary info.

[kev67]

Way over my head is this, but I get the attached error message. Called Sagepay and they say this below which means absolutely nothing to me


The error message itself is not always entirely accurate, as it is displayed when there is any kind of issue with the Notification response we receive in reply to our post to your NotificationURL. The following is a list of various known issues that you / your developers can investigate:

1) You can acknowledge receipt of the transaction response with a Status of either OK, INVALID or ERROR

2) Before writing the three fields above to the Response object of the POST, please ensure you clear your response buffer to remove any header code, comments or HTML. The Sage Pay Server is expecting "Status=" to be the first characters in the response. If it does not see these, it treats the response as though it is an error and fails the transaction!

3) Your Notification Page should ONLY respond with a Status field, a RedirectURL field and optionally a StatusDetail field. No other HTML, headers, comments or text should be included either before or after these fields. The Sage Pay Server will treat all such text as an error and fail the transaction

4) Regardless of status, the RedirectURL must be sent that contains a valid, Fully Qualified URL (i.e. an address starting http:// or https:// ) to the final completion page on your site to which Sage Pay will send your customer

5) Encoding must be as Name=Value fields separated by carriage-return-linefeeds (CRLF)

6) Your notification page on your server may be 'crashing' and you should check to ensure that the notification page on your server can handle correctly all the message sent by Sage Pay (OK, ABORT, NOTAUTHED, REJECTED, PENDING and ERROR).

7) You should send OK in all circumstances where no errors occur in validating the Notification POST, so even if Sage Pay send you a status of ABORT or NOTAUTHED, you should reply with an OK and a RedirectURL that points to a page informing the customer that the transaction did not complete.

8) Sage Pay gateway operates on a variety of fixed IP addresses and we usually use separate IP addresses to respond to all transaction requests.

Please ensure that all of the following IP addresses are allowed within your Server or Firewall:

For outbound traffic to our gateway:

195.170.169.9 - live.sagepay.com

195.170.169.8 - test.sagepay.com

For inbound traffic you only need to whitelist IPs if you are using SERVER as this is the only solution that initiates call backs. You don't need to apply this for our FORM and DIRECT integrations. The IPs from which we call back are:

195.170.169.14

195.170.169.18

195.170.169.15

The Subnet mask used by Sage Pay is 255.255.255.000

Please ensure that your firewalls allow outbound Port 443 (HTTPS only!) and inbound Ports 443 (and optionally 80 HTTP) access in order to communicate with our servers (on Simulator/Test/Live).

There is however always scope for this to change depending on how we a utilising our data centres servers. Sage Pay own the entire 195.170.169.0/255 range (256 IP's). If you are happy to allow this range then this automatically accommodates any future changes.

9) Are you matching the transaction correctly on your database using the 'SecurityKey' we passed to your notification page with the NextURL

10) If the MD5 signatures match, your Notification Script should respond with a Status of OK and a RedirectURL pointing to either an order completion page (if the Status was OK) or an appropriate order failure page (if the Status was NOTAUTHED or ERROR). You may wish ABORT messages to redirect the customer to a page providing them with alternative methods of payment, or asking them why they chose to cancel. If the signatures do not match, you should check that your code is rebuilding the message correctly, and if you are sure that it is, all such messages should be responded to with an INVALID and a RedirectURL pointing the user to a failure page.