Reload page when different radio options selected

Hi,

It is normal that it goes to the next step. It makes complete sense. for most cases and even on your website I don't see why that would be a problem.
Anyway, I've changed that on your website by changing the line:
if(($old_payment_id!=$payment_id || $old_payment_method!=$payment) && $this->_getStep('confirm',(int)$this->previous)===(int)$this->previous){

to:
if(($old_payment_id!=$payment_id || $old_payment_method!=$payment)){

in components/com_hikashop/controllers/checkout.php
Note however that we won't include that change by default in HikaShop so be careful when you update.

Regarding the issue with the payment method selection reset after the address step, after changing back the checkout workflow, I was not able to reproduce the issue on your website. Did you change something else maybe ?

Since both issues seems resolved right now, I'm leaving the checkout workflow as you wanted it.

Will this change work if I change the workflow? I want payment method selection and delivery method selection to be on the first page.

It is obvious that the second problem cannot be reproduced, becouse it occurs only when payment/delivery method selection is before registration. I had to move it after registration to work around the problem. I could change it back if someone will look at it, but I cant change it for a week.

Regarding;

" It makes complete sense. for most cases and even on your website I don't see why that would be a problem."

I will explain again. I want payment/delivery method selection to be on the first page. Also, I want my customer to see price update after he/she changes delivery/payment method. It makes no sense at all, that flow advances to another page, becouse customer WILL NOT see price update. IT MAKES NO SENSE ON ANY PAGE that customer does not see the effect of his actions.

I see that You have already changed the workflow on my page. And contrary to what you have written, the second (bigger) bug is easily reproducable. I have just reporoduced it before. You order anythink, you select second payment option (not the one that is selected by default, and you register (not login, you have to register as a new customer). And that is it. System behaves as if customer have selected first (default) payment method.

Regarding You 'fix' - don't You think that the source of the problem is that the code:

$old_payment_method!=$payment

is not working?

Your 'fix' seems to me like a hack. The problem is that the system does not see payment method change.

My modification is indeed not a fix but a hack to make it work like you want. If it was a fix I would have told you that we would include it in next versions which was not the case.
What you're missing is that the after_payment function needs to work for all the possible combinations of checkout workflows and all the possible ways you can configure the options of the checkout. You can't just remove a check like that as it would then not work properly for 30% of cases. So no, just removing $old_payment_method!=$payment is not a viable solution.

You said

It is obvious that the second problem cannot be reproduced, because it occurs only when payment/delivery method selection is before registration. I had to move it after registration to work around the problem.

but no, I actually tried with the payment and shipping selection before the registration step and didn't had the issue. Just to make sure, I wanted to try again today but I can see that you changed your checkout workflow back and I can't access your backend to change it again, so I can't test.