Kryptronic Software Support Forum

You are viewing this forum as a guest. Login to an existing account, or create a new account, to reply to topics and to create new topics.

#1 05-08-2019 08:05:42

sdn
Member
From: UK
Registered: 05-29-2007
Posts: 790

Odd Checkout Behaviour

We have noticed a few anomalies in the past few days with order checkout.

One order came through will a premium shipping option applied but the SagePay card payment received was for standard free delivery. I do not remember that ever happening before. Payment amounts have always matched the order amount.

Another odd thing reported today was a customer who originally had "UK - England & Wales" correctly set for their delivery and billing address but discovered the first line of his address was duplicated in "Address: Line 2" even though he had no put it there. Upon attempting to correct that, he found the country kept being changed to "UK - Isle of Man" on both billing and delivery addresses and he could not get rid of the Line 2 info.

We have had similar reports of address update issues. Is this likely to be some sort of session cookie error or something else?


Simon

Offline

 

#2 05-09-2019 07:19:55

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19241
Website

Re: Odd Checkout Behaviour

I'm not sure what's going on there.  We've got clients upwards of 1000 of transactions a day and have had no reports like this (and I'm sure we would have).  Are there any custom modifications in this installation that could potentially cause issues?  One thing we could do is open a ticket to do a compare of your install to stock to see if there are any differences - perhaps due to incorrectly updating the software or to locate modifications that may be negatively affecting operation.


Nick Hendler

Offline

 

#3 05-09-2019 07:35:55

sales@gobrushless.com
Member
Registered: 11-30-2011
Posts: 1

Re: Odd Checkout Behaviour

Hello
Im not sure if this is the right place to ask but I am hoping someone can help.

what is the proper way to configure khxc.curl_proxyhttps and if it can be enabled? I am running an old ClickCartPro (6.0.6), and need to use a proxy to bypass Paypals TLS 1.2 requirements.

Offline

 

#4 05-10-2019 01:39:00

sdn
Member
From: UK
Registered: 05-29-2007
Posts: 790

Re: Odd Checkout Behaviour

I am not aware of any code changes we have made that could have caused it.

I tested my hypothesis and found I can create the same effect by using the browser back button (Firefox Quantum 66.0.3, 64-bit) rather than the SagePay "Cancel" button.

After I backed out, I changed the shipping method and then used K9 "Continue" button to go back into SagePay I got the SagePay message "Error processing transaction". I backed out again using the browser back button and immediately used the K9 "Continue" button to go back into SagePay again. There was no error message that time but the payment amount was wrong but I could have proceeded with the rest of the payment process.

I managed to create the same scenario multiple times so it is not just a one off but a constant glitch than you can repeat for yourself. I will open a ticket so you can do just that.

Last edited by sdn (05-10-2019 02:29:53)


Simon

Offline

 

#5 05-10-2019 05:23:40

zanart
Member
From: bedford
Registered: 04-02-2008
Posts: 1592
Website

Re: Odd Checkout Behaviour

We get this from time to time, and it is always when the user clicks the Back Button on the Sagepay payment page instead of the cancel button.
Sometimes K9 creates a new order number, sometimes it doesn't. If user proceeds to sagepay again with same order number, they will get an error on sagepay payment page as they cannot use duplicate order numbers.

If user has selected a higher rate postal service and clicks the back button when on sagepay payment page, they are returned to the checkout page. The higher rate postal service is shown as selected in the radio button list of delivery options, but the order totals revert to the default postage service.

If they then click continue, they will pay the default postage charge, but the order details will include the higher rate postal service.

Therefore the checkout page needs to refresh if the back button is clicked on the sagepay page.

Not sure if this is possible as it will mean refreshing the page after initial load, or it will mean checking for postal method selection before the totals are calculated on initial load.


- Euorpacart 8

Offline

 

#6 05-10-2019 06:20:39

sdn
Member
From: UK
Registered: 05-29-2007
Posts: 790

Re: Odd Checkout Behaviour

Yes, I expect you are correct on those points.

I performed more testing and found the problem is worse than I first thought. SagePay/K9 got stuck in an eternal loop where I got the SagePay message "Error processing transaction" and "5080 : Form transaction registration failed.".

I even tried deleting the carts contents, adding different items and I still got the SagePay error.

In SagePay,  under the Invalid transactions report, I see that K9 is submitting the same order ID but with different order values which is triggering the SagePay error.

You can't stop people using the back button and I suspect it is quite common that people do. K9 needs to recognise this has happened and I assume create a fresh order ID when the details are resubmitted to SagePay.

Last edited by sdn (05-10-2019 06:42:13)


Simon

Offline

 

#7 05-10-2019 06:55:55

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19241
Website

Re: Odd Checkout Behaviour

A support ticket was opened for this issue and I will follow up there and work with you on a resolution.


Nick Hendler

Offline

 

#8 05-10-2019 10:17:30

zanart
Member
From: bedford
Registered: 04-02-2008
Posts: 1592
Website

Re: Odd Checkout Behaviour

The ‘eternal loop’ does happen to us, but it is very rare so I have never really worried about it.
I usually tell the customer to try again in the morning, as new order numbers seem to be issued the next day for pending payment orders.


- Euorpacart 8

Offline

 

#9 05-11-2019 18:29:48

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19241
Website

Re: Odd Checkout Behaviour

We're currently working on sdn's site to provide a resolution to this issue, which will be posted here when we find it.  Thank you all for input thus far.


Nick Hendler

Offline

 

#10 05-16-2019 05:54:12

sdn
Member
From: UK
Registered: 05-29-2007
Posts: 790

Re: Odd Checkout Behaviour

Related to this issue is another we have noticed concerning the delivery address selection.

Our test shopper account has 4 different delivery address entries. We have noticed that if you go to the Checkout page, it seems to always default to 3rd entry. If we change this to another address and then add or remove an item to the basket, the address has gone back to the 3rd one when we go to the Checkout page again.

We have had customers reporting issues with making changes to their address book that then revert back again making it impossible to checkout with the correct address. Some have just given up and presumably purchased elsewhere and a few have called us to ask for help.

So there is something not quite right there...

Last edited by sdn (05-16-2019 05:57:57)


Simon

Offline

 

#11 05-16-2019 07:04:33

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19241
Website

Re: Odd Checkout Behaviour

If checkout is reached by a user without any address selections previously in checkout (or their cart has changed) and they have a delivery address book present, the last delivery address added (that is not the billing address) will be used as the default.


Nick Hendler

Offline

 

#12 05-16-2019 08:29:49

sdn
Member
From: UK
Registered: 05-29-2007
Posts: 790

Re: Odd Checkout Behaviour

So you mean that the cart will always default to the last "entered" delivery address rather than the last "used" address? That might be quite annoying if the last address entered was only infrequently required.

How much work would it be to add a "Set as default delivery address" checkbox so the customer can choose the one they prefer?

Last edited by sdn (05-16-2019 08:32:37)


Simon

Offline

 

#13 05-17-2019 07:09:29

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19241
Website

Re: Odd Checkout Behaviour

sdn wrote:

So you mean that the cart will always default to the last "entered" delivery address rather than the last "used" address? That might be quite annoying if the last address entered was only infrequently required.

Correct.  By "last used" I guess you mean if the customer ordered before and they used a different address than what's last.  Checkout does not look up order history to see what might have been last used.

sdn wrote:

How much work would it be to add a "Set as default delivery address" checkbox so the customer can choose the one they prefer?

This can be added.  In 9.0.4 we plan to expand the delivery address book to include a delivery phone number.  I'll make a note to add a "make this my preferred delivery address" field as well. 

99 times out of 100 the last address book entry is exactly what the customer wants.  Previous versions defaulted to the billing address, then we tried the first delivery address in the address book and found that the methodology used now satisfies all but 1% of use cases.  But we can do more (see above).


Nick Hendler

Offline

 

#14 05-22-2019 02:50:38

sdn
Member
From: UK
Registered: 05-29-2007
Posts: 790

Re: Odd Checkout Behaviour

Say I added a new address to my address book so that I could send a one-off birthday present to a friend. Are you saying that K9 will now make that my new default delivery address?


Simon

Offline

 

#15 05-22-2019 05:30:05

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19241
Website

Re: Odd Checkout Behaviour

Say I added a new address to my address book so that I could send a one-off birthday present to a friend. Are you saying that K9 will now make that my new default delivery address?

Assuming that was the last delivery address you added, yes.  The last delivery address added to the address book becomes the default selection in checkout.  As I said before, that's desired behavior in nearly all checkout scenarios.  During the session when you added that address to your address book you would expect that to be the selected address.  It would only be on a return visit where you might want to ship to an address used on prior orders (and not the last one you used) where this might pose an issue for you.


Nick Hendler

Offline

 

#16 05-22-2019 06:40:50

sdn
Member
From: UK
Registered: 05-29-2007
Posts: 790

Re: Odd Checkout Behaviour

I think we have been talking about different scenarios.

I agree, that if I were to add a new delivery address, that I would want the cart to keep using that address until I had completed the order / checked out.

But I would not want that one time delivery address to keep appearing as my new default delivery address for all future orders I might wish to place.

Last edited by sdn (05-22-2019 06:41:44)


Simon

Offline

 

#17 05-24-2019 06:41:38

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19241
Website

Re: Odd Checkout Behaviour

Right, but the system doesn't keep track of when those delivery addresses were added, and couldn't guess whether the last added address is not to be the default.  That's why we're going to add a 'make this my default delivery address' field in an upcoming version.


Nick Hendler

Offline

 

#18 05-24-2019 13:23:35

sdn
Member
From: UK
Registered: 05-29-2007
Posts: 790

Re: Odd Checkout Behaviour

OK I understand this now.

I did some testing with debug on to see if any errors reported with checkout. When returned to the checkout page using the SagePay "cancel" button I get:

CORE_Error::error: Non-fatal error encountered: Function mcrypt_encrypt() is deprecated File: /core/CORE_Display/CORE_Display.php(455) : eval()'d code Line: 204

CORE_Error::error: Non-fatal error encountered: Undefined index: gateway File: /apps/ecom/ECOM/includes/olpform.php Line: 125 (this one also reported if returning from PayPal login screen)

Are they a problem?

Last edited by sdn (05-24-2019 13:31:40)


Simon

Offline

 

#19 05-27-2019 06:35:04

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19241
Website

Re: Odd Checkout Behaviour

No, neither are an issue, but I will ensure they are addressed.


Nick Hendler

Offline

 

Board footer