Closed magnuskl closed 3 years ago
Hi,
It seems like you are correct. The total price should now be $subscription->get_total() + $order->get_total()
when a variation upgrade happens, but not when a downgrade happens.
I will have to look around a little bit and see how other recurring gateways deal with this issue I think as it doesn't sound like a good solution to be performing conditional arithmetic 😅
I've made a few commits that should fix this issue (ddfa15fa87a7c16289fed8b6ae89a8d20bf43a04 and 4903223937f7d0f70e65df58a0a15bc307da5984).
I have not thoroughly tested everything yet so this update will not be landing on WordPress.org yet, but you're free to test it out by downloading the plugin from GitHub.
As always with code that hasn't been thoroughly tested yet (now that WooCommerce merged my e2e testing fix I should be able to make some automated tests soon 😅) I recommend being careful if you do decide to try it out before the update is ready 😀
Splendid! I will test your update tomorrow and let you know about any findings. I made a “duct tape fix” myself, which I would rather substitute with something more durable :-)
Hey @magnuskl – have you been able to test the update? 😊
WooCommerce Subscriptions allows switching between subscription variations and grouped subscriptions. However, Vipps Recurring Payments for WooCommerce does not handle this use case correctly, as the new subscription maintains the old recurring cost. The upfront cost—prorated or not—calculates as it should. The problem seems to emerge from how
process_payment
defines$agreement_total
, which translates to the recurring cost in the payment agreement: its value is derived from the order total of the related subscription—and this happens before WooCommerce Subscriptions performs recalculation. The problem is an insidious one, since everything appears normal on the WooCommerce front end, while the actual payment agreement does not concur.