Payment inconsistency related to payment provider and custom order line calculator
I have implemented an order line calculator that override the original unit price by collecting prices from an external API. Everything is working fine until I select Stripe as the payment provider.
The payment captured by Stripe is correct, but the finalized orders total amount is incorrect compared to the order line calculator. The finalized order is now showing the original unit prices and not the calculator prices.
The order line calculator collects prices by posting a customerID and productID to an API. The customerID is an custom order property and the productID is an custom order line property, so the problem is not related to different sessions, like the case described in this thread with a similar problem.
Looking at the calculation logic for TC, it should indeed only recalculate order lines if the order isn't yet finalized, but after this point it should just use whatever order lines prices were previously calculated.
It seems like the problem was related to the Stripe webhooks. I have been testing the solution on different sub domains, and there was created multiple webhook endpoints in Stripe. Every time I save the Stripe payment provider in Umbraco a new Stripe webhook is created. I did a manually cleanup and disable some endpoints and generated a new for my test domain. The finalized orders total amount is now correct, so the problem seems to be solved, although I do not quite understand why 😊
My Umbraco installation contains two Tea commerce stores (different sub domains), both using Stripe as the payment provider. Can this cause a webhook problem? I guess the stores need different webhook endpoints. Perhaps its better to create a shared endpoint manually and disable the ones auto generated?
Ahhh, yea, the Stripe payment provider went through a few iterations quickly when the Stripe API changed and I believe one of those iterations attempted to create the webhook registrations automatically. I do believe in the latest version of the code this isn't the case anymore and I think it's a manual registration again.
Having two stores using Stripe shouldn't be a problem, except (and this might actually be the reason for the problem) where both stores use the same order number prefix. The reason this is a problem is because it's the order number that is used to look up the order and so if you have two orders in different stores, it can get confused which order to use and thus is chooses the wrong one and you get issues like this.
I don't think we can currently create a shared endpoint as the webhook urls contain information that tell which payment provider to invoke the request on, so you do currently need a unique webook per store.
Now I understand why the price calculator failed. The test installation of the store shares database with the live installation. The price calculator is missing on the live server, so this of course caused a problem with the price calculation as it was an active webhook pointing to this installation.
My lack of control over active webhooks was the reason for the problems.
Payment inconsistency related to payment provider and custom order line calculator
I have implemented an order line calculator that override the original unit price by collecting prices from an external API. Everything is working fine until I select Stripe as the payment provider.
The payment captured by Stripe is correct, but the finalized orders total amount is incorrect compared to the order line calculator. The finalized order is now showing the original unit prices and not the calculator prices.
The order line calculator collects prices by posting a customerID and productID to an API. The customerID is an custom order property and the productID is an custom order line property, so the problem is not related to different sessions, like the case described in this thread with a similar problem.
All feedback is appreciated
Arne
Hey Arne,
This is strange indeed.
Looking at the calculation logic for TC, it should indeed only recalculate order lines if the order isn't yet finalized, but after this point it should just use whatever order lines prices were previously calculated.
Have you been able to replicate this locally? If so, I wonder if the best course of action would be to grab the source code for the Stripe provider here https://github.com/TeaCommerce/Tea-Commerce-Payment-Providers/tree/master/Source/TeaCommerce.PaymentProviders.Stripe, compile it in debug mode and set breakpoints in the various
ProcessRequestmethods to see if we can nail down at what point, and what actions cause the prices to change.Whilst the following link is for our Vendr ecommerce product, it should hold true for helping test the webhook locally so you can verify the webhook handling of payments https://vendr.net/docs/payment-providers/stripe/1-1-0/stripe-checkout/how-to-guides/testing-stripe-webhooks-locally/
Give these a try and see if you are able to work out the moment the prices change.
Hope this helps
Matt
Hi and thanks for your reply
It seems like the problem was related to the Stripe webhooks. I have been testing the solution on different sub domains, and there was created multiple webhook endpoints in Stripe. Every time I save the Stripe payment provider in Umbraco a new Stripe webhook is created. I did a manually cleanup and disable some endpoints and generated a new for my test domain. The finalized orders total amount is now correct, so the problem seems to be solved, although I do not quite understand why 😊
My Umbraco installation contains two Tea commerce stores (different sub domains), both using Stripe as the payment provider. Can this cause a webhook problem? I guess the stores need different webhook endpoints. Perhaps its better to create a shared endpoint manually and disable the ones auto generated?
Arne
Hey Arne,
Ahhh, yea, the Stripe payment provider went through a few iterations quickly when the Stripe API changed and I believe one of those iterations attempted to create the webhook registrations automatically. I do believe in the latest version of the code this isn't the case anymore and I think it's a manual registration again.
Having two stores using Stripe shouldn't be a problem, except (and this might actually be the reason for the problem) where both stores use the same order number prefix. The reason this is a problem is because it's the order number that is used to look up the order and so if you have two orders in different stores, it can get confused which order to use and thus is chooses the wrong one and you get issues like this.
I don't think we can currently create a shared endpoint as the webhook urls contain information that tell which payment provider to invoke the request on, so you do currently need a unique webook per store.
Hope this helps
Matt
Thanks again
Now I understand why the price calculator failed. The test installation of the store shares database with the live installation. The price calculator is missing on the live server, so this of course caused a problem with the price calculation as it was an active webhook pointing to this installation.
My lack of control over active webhooks was the reason for the problems.
Arne
is working on a reply...