Great work on Vendr, enjoying using it so far, seems very well built and flexible.
One question I have is regarding shipping calculators... So, I've replaced the default ShippingCalculator with one of my own. It's logic is simple (for now), if an order exceeds a certain total value, shipping is set to 0 (free), otherwise we use the value set in the backoffice for the shipping method.
This works as expected and there were no issues at all until i installed the Stripe payment provider and completed a test order.
ISessionManager is injected in to my custom Shipping Calculator and I use the GetCurrentOrder method (also tried using GetCurrentFinalizedOrder when GetCurrentOrder returns null). This is fine when the request is in context, but when executed out of context of the session (via the Stripe webhook) it errors, which kind of makes sense. I can't see how I can reliably get a reference to the specific order we're calculating for in a ShippingCalculator?
Should the stripe payment provider be setting the finalized order at some point?
I may be approaching this wrong, if so I'd appreciate your wisdom 😁 But if not, it feels as though there must be a way to do this or perhaps it's an issue? Being able to reliably access the Order within a Shipping Calculator would open up a world of possibilities.
It feels like this should maybe be a discount rather than a custom shipping calculator.
You should be able to create an automatic discount that applies to orders that use a specific shipping method and with an order total greater than a specific amount and then you can apply a reward to make the shipping zero.
You can create customer discount rules / rewards if you need some additional logic.
The Shipping Calculator isn't really designed to be context aware in this way.
Thanks for the rapid reply. I did feel as though I was trying to shoehorn context in to the calculator.
I've implemented your solution which is great, works as expected. The only issue is I can't see how I would display the discounted shipping price on a select shipping method step in the checkout - since the discount won't be applied until after it's selected. Not the end of the world, but could have an affect on conversions.
The solution you've outlined works for this simple scenario of discounting shipping methods, but it would be really nice to be able to do some funky shipping calculations based on order/order line properties! Unfortunately this is a bit of a show-stopper for some other projects I was hoping to use Vendr for 😣 unless there is another way I could implement more complex shipping calculations? Think varying shipping cost; by weight, by postcode (I know, horrible, but they want it). Wouldn't we need some sort of Order context in the calculator if we were to create a shipping calculator that used a courier's API?
I’ll need to think how we can do this. We could pass in an order, but during order calculation, the order isn’t updated till the end. During calculation we have an OrderCalculation object that gets updated with the running totals. We could pass both, but I think there are scenarios where you can call the calculate outside of the order calculation process so would potentially mean you’d have to implement 2 methods, one with and one without an order calculation context, or just the one method, but we say order calculation could be null.
Would you mind raising this on the Vendr issue tracker as a feature request to pass more context to the shipping calculator? I can then ensure it doesn't get lest.
Hmm, that could, although I guess if it's a webhook request it shouldn't.
If you wanted to be on the safe side you could maybe store it in the request cache so you know it would only be around for the current request. Setting the sessions current order will create a cookie which I wouldn't want that affecting future webhook requests.
Shipping Calculator with Order context
Hi Matt,
Great work on Vendr, enjoying using it so far, seems very well built and flexible.
One question I have is regarding shipping calculators... So, I've replaced the default
ShippingCalculatorwith one of my own. It's logic is simple (for now), if an order exceeds a certain total value, shipping is set to 0 (free), otherwise we use the value set in the backoffice for the shipping method.This works as expected and there were no issues at all until i installed the Stripe payment provider and completed a test order.
ISessionManageris injected in to my custom Shipping Calculator and I use theGetCurrentOrdermethod (also tried usingGetCurrentFinalizedOrderwhenGetCurrentOrderreturns null). This is fine when the request is in context, but when executed out of context of the session (via the Stripe webhook) it errors, which kind of makes sense. I can't see how I can reliably get a reference to the specific order we're calculating for in a ShippingCalculator?Should the stripe payment provider be setting the finalized order at some point?
I may be approaching this wrong, if so I'd appreciate your wisdom 😁 But if not, it feels as though there must be a way to do this or perhaps it's an issue? Being able to reliably access the Order within a Shipping Calculator would open up a world of possibilities.
Any help or advice would be greatly appreciated.
Cheers, Jason
Hi Jason,
It feels like this should maybe be a discount rather than a custom shipping calculator.
You should be able to create an automatic discount that applies to orders that use a specific shipping method and with an order total greater than a specific amount and then you can apply a reward to make the shipping zero.
You can create customer discount rules / rewards if you need some additional logic.
The Shipping Calculator isn't really designed to be context aware in this way.
Hope this helps
Matt
Thanks for the rapid reply. I did feel as though I was trying to shoehorn context in to the calculator.
I've implemented your solution which is great, works as expected. The only issue is I can't see how I would display the discounted shipping price on a select shipping method step in the checkout - since the discount won't be applied until after it's selected. Not the end of the world, but could have an affect on conversions.
The solution you've outlined works for this simple scenario of discounting shipping methods, but it would be really nice to be able to do some funky shipping calculations based on order/order line properties! Unfortunately this is a bit of a show-stopper for some other projects I was hoping to use Vendr for 😣 unless there is another way I could implement more complex shipping calculations? Think varying shipping cost; by weight, by postcode (I know, horrible, but they want it). Wouldn't we need some sort of Order context in the calculator if we were to create a shipping calculator that used a courier's API?
Cheers, Jason
Hi Jason,
Some good points for sure.
I’ll need to think how we can do this. We could pass in an order, but during order calculation, the order isn’t updated till the end. During calculation we have an OrderCalculation object that gets updated with the running totals. We could pass both, but I think there are scenarios where you can call the calculate outside of the order calculation process so would potentially mean you’d have to implement 2 methods, one with and one without an order calculation context, or just the one method, but we say order calculation could be null.
Either way, I think it should be possible.
Quick request.
Would you mind raising this on the Vendr issue tracker as a feature request to pass more context to the shipping calculator? I can then ensure it doesn't get lest.
https://github.com/vendrhub/vendr/issues
Many thanks
Matt
Sure, I've opened a feature request https://github.com/vendrhub/vendr/issues/146
I've actually found a bit of a workaround to my initial approach to this where I was injecting
ISessionManagerin to the calculator.If I set the order in the payment provider's
ProcessCallback(as I have here https://github.com/jlarc/vendr-payment-provider-stripe/commit/a50a7ece81eb671da7e5a89fcd8da28c08b7f476) then I can at least continue to use the Session Manager approach for now. I'm unsure whether this will have any unwanted side effects though. Seems to work so far.Cheers, keep up the good work on Vendr 😀
Hmm, that could, although I guess if it's a webhook request it shouldn't.
If you wanted to be on the safe side you could maybe store it in the request cache so you know it would only be around for the current request. Setting the sessions current order will create a cookie which I wouldn't want that affecting future webhook requests.
PS Thanks for raising the issue. I'll take a look as soon as I can 👍
is working on a reply...