The Vendr store on our site is experiencing occasional 'order' loss upon returning from the Global Payments payment gateway.
As of yet we've not been able to determine why this is happening. I can put an order through our checkout/cart and it will successfully process then later I can put the same order details through and it will fail.
The one thing I can pin down when an order is lost is that when returning from the payment gateway the site's TempData (and Session data) is empty. When the order is a success, TempData and Session data are populated, when there is an error they are empty.
The only way I can recreate this every time in my local dev environment is by actually attaching to a process locally and stepping through the code - it seems that by doing this and turning the order checkout process into a much longer process it seems to cause this data reset/fail every time.
Does anyone have any suggestions on what could be causing our data (order, TempData and Session data) to be lost upon return from a payment gateway when the only thing we have to go on is "when the order takes a longer time to go through the order process it fails"?
Hmm, that sounds pretty weird. It's not one of heard of before.
I'm guessing when you say "order is lost", you mean it's being removed from session and so the customer sees a blank order (but the order still exists in the system, it's just no longer the customers order)
Few things that cross my mind to check are
1) What's your hosting setup? Is this load balanced? Is the customer being redirected back to a different endpoint and so their session is not present?
2) Vendr uses cookies to remember the current order, what is the cookie timeout setting in your Stores settings? Is it long enough to complete a checkout? Is the Vendr cookie still present? or is this getting lost as well?
3) I'm guessing this is a custom Payment Provider. Is there anything in it's setup that could be finalizing the order too early? When an order is finalized, it moves from "current order" in the session to "current finalized order". So you need to make sure you are checking the right location.
Thanks for responding. Yes, 'order is lost' meaning when the checkout process calls VendrApi.Instance.GetCurrentOrder() it's returning null upon return (but not every time).
I should probably clarify before I answer that, as an external dev with limited access and just joining the project I'm just getting up to speed on the setup so apologies if I don't have all the info handy.
(1) For the hosting setup, I would need to check out the load-balancing situation. I know the hosting is Azure-based. At the moment I'm running a localy copy of the site with a manually copied database locally to just step through the code to see if anything obvious was jumping out. For the endpoint it looks to me that it's the same endpoint I'd expect.
(2) The Vendr cookie timeout is currently set at 525600 - and it does still seem to persist - is that something that can be used?
(3) The payment provider is Global Payments. I don't see anything code-wise finalizing the order too quickly. It seems the longer I spend i.e. 10 seconds or more on the payment provider the problem occurs whereas if I just race through the order it completes ok.
I appreciate your help and realise the information provided isn't much to go on. I am reaching out to the payment gateway as well to see what they advise.
FYI, I checked the versions and the site is currently running on: Vendr v1.4.1, Umbraco v8.10.1
There is nothing jumping out at me there as to why this would be happening then.
I can't think why holding on the payment gateway would cause this problem though. There shouldn't be anything in that process, other than finalizing the order that should trigger that.
What Vendr cookies do you actually have when it goes wrong? If the order gets moved to the finalized state for some reason, there should be an extra cookie that holds the current finalized order. If your order has been moved to the finalized state, then we should see it in this cookie.
Vendr Order being lost upon payment gateway return
Hi,
The Vendr store on our site is experiencing occasional 'order' loss upon returning from the Global Payments payment gateway.
As of yet we've not been able to determine why this is happening. I can put an order through our checkout/cart and it will successfully process then later I can put the same order details through and it will fail.
The one thing I can pin down when an order is lost is that when returning from the payment gateway the site's TempData (and Session data) is empty. When the order is a success, TempData and Session data are populated, when there is an error they are empty.
The only way I can recreate this every time in my local dev environment is by actually attaching to a process locally and stepping through the code - it seems that by doing this and turning the order checkout process into a much longer process it seems to cause this data reset/fail every time.
Does anyone have any suggestions on what could be causing our data (order, TempData and Session data) to be lost upon return from a payment gateway when the only thing we have to go on is "when the order takes a longer time to go through the order process it fails"?
Hi Derek,
Hmm, that sounds pretty weird. It's not one of heard of before.
I'm guessing when you say "order is lost", you mean it's being removed from session and so the customer sees a blank order (but the order still exists in the system, it's just no longer the customers order)
Few things that cross my mind to check are
1) What's your hosting setup? Is this load balanced? Is the customer being redirected back to a different endpoint and so their session is not present?
2) Vendr uses cookies to remember the current order, what is the cookie timeout setting in your Stores settings? Is it long enough to complete a checkout? Is the Vendr cookie still present? or is this getting lost as well?
3) I'm guessing this is a custom Payment Provider. Is there anything in it's setup that could be finalizing the order too early? When an order is finalized, it moves from "current order" in the session to "current finalized order". So you need to make sure you are checking the right location.
Hi Matt,
Thanks for responding. Yes, 'order is lost' meaning when the checkout process calls VendrApi.Instance.GetCurrentOrder() it's returning null upon return (but not every time).
I should probably clarify before I answer that, as an external dev with limited access and just joining the project I'm just getting up to speed on the setup so apologies if I don't have all the info handy.
(1) For the hosting setup, I would need to check out the load-balancing situation. I know the hosting is Azure-based. At the moment I'm running a localy copy of the site with a manually copied database locally to just step through the code to see if anything obvious was jumping out. For the endpoint it looks to me that it's the same endpoint I'd expect.
(2) The Vendr cookie timeout is currently set at 525600 - and it does still seem to persist - is that something that can be used?
(3) The payment provider is Global Payments. I don't see anything code-wise finalizing the order too quickly. It seems the longer I spend i.e. 10 seconds or more on the payment provider the problem occurs whereas if I just race through the order it completes ok.
I appreciate your help and realise the information provided isn't much to go on. I am reaching out to the payment gateway as well to see what they advise.
FYI, I checked the versions and the site is currently running on: Vendr v1.4.1, Umbraco v8.10.1
Thanks, Derek
Hmm
There is nothing jumping out at me there as to why this would be happening then.
I can't think why holding on the payment gateway would cause this problem though. There shouldn't be anything in that process, other than finalizing the order that should trigger that.
What Vendr cookies do you actually have when it goes wrong? If the order gets moved to the finalized state for some reason, there should be an extra cookie that holds the current finalized order. If your order has been moved to the finalized state, then we should see it in this cookie.
Matt
is working on a reply...