Hmm, then I can't see any reason why it wouldn't get cleared. Especially if the invoice payment method is clearing. If the payment provider code finished successfully, then the same internal code should be running to clear the order 🤔
The same happens on my local dev environment and our staging server (same code version), and it happens for everyone. So, it's not a peculiar thing with my setup.
So, is the basket cleared in code internal to TeaCommerce?
Essentially we have a SessionManager that stores keys in the session / cookie. When you request info from the session (ie, the current order) it first checks if things have changed and if so updates those id's, so on the finalize order screen when you fetch your finalized order, it should really have cleared out the "currentOrderId".
Does the cart you are seeing belong to the order that was processed do you know? (ie, are they the same order id?) or has it replicated the cart?
Hmm, the only way I know that an order gets "cloned" is if you attempt to modify it when it's mid payment processing. I don't suppose you have any events that are triggering and modifying the order as it's being processed?
If you have the store with cookies enabled, maybe review the cookie pre and post checkout to see what it contains. With cookies enabled, this should contains ID's for the current order / current finalized order etc.
Not sure if / how this helps, but I recorded the cookie during 2 successive orders without altering the basket (it retained the first ordered product):
First order, on Payment Page:
currentShippingMethodId=5¤tOrderId=¤tPaymentCountryId=3¤tPaymentCountryRegionId=¤tShippingCountryId=3¤tShippingCountryRegionId=¤tPaymentMethodId=10007¤tPaymentProcessingOrderId=fe0c7a54-0d5b-48db-92e7-f0f5e45809c9
First Order, Confirmation page:
currentShippingMethodId=5¤tOrderId=4a759852-076c-48f8-a494-4944f3d9b7aa¤tPaymentCountryId=3¤tPaymentCountryRegionId=¤tShippingCountryId=3¤tShippingCountryRegionId=¤tPaymentMethodId=10007¤tPaymentProcessingOrderId=¤tFinalizedOrderId=fe0c7a54-0d5b-48db-92e7-f0f5e45809c9
Straight back to Basket page:
currentShippingMethodId=5¤tOrderId=4a759852-076c-48f8-a494-4944f3d9b7aa¤tPaymentCountryId=3¤tPaymentCountryRegionId=¤tShippingCountryId=3¤tShippingCountryRegionId=¤tPaymentMethodId=10007¤tPaymentProcessingOrderId=¤tFinalizedOrderId=fe0c7a54-0d5b-48db-92e7-f0f5e45809c9
Second order, on Payment Page:
currentShippingMethodId=5¤tOrderId=¤tPaymentCountryId=3¤tPaymentCountryRegionId=¤tShippingCountryId=3¤tShippingCountryRegionId=¤tPaymentMethodId=10007¤tPaymentProcessingOrderId=4a759852-076c-48f8-a494-4944f3d9b7aa¤tFinalizedOrderId=fe0c7a54-0d5b-48db-92e7-f0f5e45809c9
Shouldn't the cookie be cleared by the time we arrive at the confirmation page?
I think I will need to force a basket empty in code!
That's some really useful info thanks. I'll try and look into this a little more closely, but yes, once you are on the confirmation page and you call GetCurrentFinalizedOrder that really should be triggering the clearing of the previous order.
Just to add the answer to this post, Gordon sent me the source for his project and it turned out there was some rogue JS attempting to modify an order post finalization which when this occurs via the TC. api, this clones the order and sets it as the current order (it does this to prevent editing an order once it's been sent to payment process).
We are looking at options to only do this in certain cercumstances (I think it only really makes sense if the transaction is canceled / errored, otherwise I think an error should be thrown.
I will see what I can come up with to resolve this, but in the meantime, the fix here is to make sure you aren't modifying an order after it has been finalized.
Basket not cleared after Stripe payment
I have the Stripe payment provider working OK, but after each successful payment, the basket still contained the ordered items.
Is that something the payment provider should handle (empty the basket) or should I?
I am also using the Invoicing payment provider and that does clear the basket.
Hey Gordon,
Is the order appearing in the back office as a finalized order? It sounds like the callback might not be firing that that finalizes the order.
Matt
The orders are appearing in TC - Order Status = New, Transaction state = Captured.
Interesting. Then yea, the basked should have been emptied.
Is there any errors in the log file?
Messages in the log, eg "INFO TeaCommerce.Api.Models.Order - Order finalized - OnFinalized finished." - but no errors.
Hmm, then I can't see any reason why it wouldn't get cleared. Especially if the invoice payment method is clearing. If the payment provider code finished successfully, then the same internal code should be running to clear the order 🤔
The same happens on my local dev environment and our staging server (same code version), and it happens for everyone. So, it's not a peculiar thing with my setup.
So, is the basket cleared in code internal to TeaCommerce?
Hey Gordon,
Yea, it is.
Essentially we have a SessionManager that stores keys in the session / cookie. When you request info from the session (ie, the current order) it first checks if things have changed and if so updates those id's, so on the finalize order screen when you fetch your finalized order, it should really have cleared out the "currentOrderId".
Does the cart you are seeing belong to the order that was processed do you know? (ie, are they the same order id?) or has it replicated the cart?
I made an order and the order number was ORDER-34, its reference-id was CART-75.
I then immediately made another order with the basket as it was (same content as before). Order number was ORDER-35 and its reference-id CART-76.
I'm not sure if that helps?!
Hmm, the only way I know that an order gets "cloned" is if you attempt to modify it when it's mid payment processing. I don't suppose you have any events that are triggering and modifying the order as it's being processed?
These are all of the event handlers we use:
They have all been in place for a long time though and none have been altered during the Stripe integration work.
Hmm, they look ok to me.
If you have the store with cookies enabled, maybe review the cookie pre and post checkout to see what it contains. With cookies enabled, this should contains ID's for the current order / current finalized order etc.
As a quick solution, you might be able to try removing the current order within your finalized handler
Not sure if / how this helps, but I recorded the cookie during 2 successive orders without altering the basket (it retained the first ordered product):
Shouldn't the cookie be cleared by the time we arrive at the confirmation page?
I think I will need to force a basket empty in code!
That seems to have fixed the issue. Fingers crossed!! :-)
That's some really useful info thanks. I'll try and look into this a little more closely, but yes, once you are on the confirmation page and you call
GetCurrentFinalizedOrder
that really should be triggering the clearing of the previous order.Glad you've got something to work never the less.
Question, can you share what code you have on your confirmation page? Mostly where you interact with TC
Can I email it to info at teacommerce dot net?
Of course 👍
Just to add the answer to this post, Gordon sent me the source for his project and it turned out there was some rogue JS attempting to modify an order post finalization which when this occurs via the
TC.
api, this clones the order and sets it as the current order (it does this to prevent editing an order once it's been sent to payment process).We are looking at options to only do this in certain cercumstances (I think it only really makes sense if the transaction is canceled / errored, otherwise I think an error should be thrown.
I will see what I can come up with to resolve this, but in the meantime, the fix here is to make sure you aren't modifying an order after it has been finalized.
is working on a reply...