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: 806

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: 19312
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: 806

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: 1602
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

Online

 

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

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

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: 19312
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: 1602
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

Online

 

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

webmaster
Administrator
From: York, PA
Registered: 04-20-2001
Posts: 19312
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: 806

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: 19312
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: 806

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: 19312
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: 806

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: 19312
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: 806

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: 19312
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: 806

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: 19312
Website

Re: Odd Checkout Behaviour

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


Nick Hendler

Offline

 

#20 07-15-2019 05:51:58

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

Re: Odd Checkout Behaviour

Still finding that the cart is pulling in delivery addresses from other sessions.

Using MS Edge to do a PayPal Express checkout, the Delivery Address is not populated with the one selected in PayPal (the Billing address is correct though). I am not logged into any K9 account in Edge.before starting checkout.

Selecting "Deliver to a Different Address" link give me two address options, the correct PayPal address and the "wrong" address. Clicking on the correct address then takes me back to checkout but I am then presented with card (Sagepay) or standard PayPal payment options (in other words, I am no longer making a PayPal Express checkout).

I assume the wrong address is being pulled in from previous session data. Is that what is intended?

I then did the same checkout using TOR browser and the delivery address was correctly populated.

I then went back to Edge and repeated the above and that too had the correct delivery address. I assume the TOR checkout straighten things out for Edge.

Last edited by sdn (07-15-2019 09:41:45)


Simon

Offline

 

#21 07-15-2019 12:28:12

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

Re: Odd Checkout Behaviour

I'm going to test this scenario in MS Edge.  Do you have a version number for what you were using?


Nick Hendler

Offline

 

#22 07-16-2019 07:48:05

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

Re: Odd Checkout Behaviour

Microsoft Edge 44.17763.1.0 on an up to date Windows 10 PC.

I don't use Edge much so thought it would give me a less corrupted user experience. I think I might have had similar issues with Firefox and Chrome but cannot recreate that at present (maybe the TOR session sorted them as well).

Should session data be shared across different browsers as appeared to be the case yesterday? I thought TOR would be completely isolated?

- - - - - - - - - - - - - -

I just tried this experiment again and used yet another "deliver to" address from my PayPal account and again I have two addresses in the final checkout page. Billing address is correct and Delivery Info is populated with the address I used for yesterdays experiment. If I click on the Delivery to a Different Address link there are now 3 delivery addresses to choose from. I am not logged into an account for any of this.

Last edited by sdn (07-16-2019 08:06:32)


Simon

Offline

 

#23 07-16-2019 09:47:43

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

Re: Odd Checkout Behaviour

If you're logging into an account the session info is centralized and stored with the account, so they are shared across different devices - if logged in.  Otherwise, for guest sessions, the data is transient and available only to the device with the guest session.


Nick Hendler

Offline

 

#24 07-16-2019 14:12:54

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

Re: Odd Checkout Behaviour

I was deliberately not logged into any account in Edge or TOR when performing the experiements but it is possible I was logged into admin in a Chrome. However, that has many test delivery addresses in it and they were not presented.

Last edited by sdn (07-16-2019 14:13:51)


Simon

Offline

 

#25 07-17-2019 07:55:35

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

Re: Odd Checkout Behaviour

OK.  The delivery address sent over by PayPal during an express checkout is locked in, unless you bail out of checkout and pick a different payment method (basically abort express checkout).  You're saying the delivery address selected at PayPal didn't match the delivery address presented in checkout?


Nick Hendler

Offline

 

Board footer