Pay for order not working

That’s a current limitation of the system; Vipps orders should not be set back to “pending” and the link to “pay for order” is normally disabled for Vipps orders on the “my orders” page. It is a point that the error message here probably should be more useful, but we intend to remove this limitation instead as soon as possible.

The original cause of the limitation is that there is no way in the Vipps API to restart an order that has failed, and there is no way to start a session with an order number/id that has already been used.

We do have a workaround for this planned, but it has to be done carefully so that we don’t allow restarting sessions that are still active by mistake.

I agree that this limitation is annoying, hopefully we can make it go away in the not too distant future.

Thank you for a quick reply. I see, so for this to work now we would have to change the order number each time a customer tries to pay for the order? Or is there another workaround you can think of that we could implement ourselves, for example with the woo_vipps_orderid filter?

• This reply was modified 5 months ago by Kim.
• This reply was modified 5 months ago by Kim.
• This reply was modified 5 months ago by Kim.

If you want to try, you can; but beware of bugs, and be aware that we are planning on implementing this in the main branch too. We’ll try to cooperate with existing code as best we can of course.

I’ll describe the planned implementation (looking at just normal payments right now; Vipps Checkout is slightly different and Vipps Express checkout orders are a bit more difficult because they are both anonymous and lack shipping.)

1. First, these orders will have the meta values ‘_vipps_init_timestamp’ and ‘_vipps_status’ already set, and should have order status ‘pending’ (or ‘failed’ I guess). Now, for “pending” orders, the Vipps session may still be active, and if it is, you should *not* do this. The user may still have the app open and be ready to pay the original order. You could first try to inspect the _vipps_status, using WC_Payment_Gateway_Vipps::instance()->interpret_vipps_order_status(). It should be ‘cancelled‘. If it isn’t, for normal orders you should just run process_payment on it because this will return the stored _vipps_orderurl, which should just inform the user that the payment is still being processed.
   
   Now, it *may be* that you cannot trust the _vipps_status meta variable, so you may need to first call the WC_Payment_Gateway_Vipps::instance()->get_payment_details($order) method to check the actual status at Vipps. This will encapsulate the differences of the various Vipps ecom APIs and should return an assoc with a ‘status‘ field, to be interpreted as above. If the status is cancelled at Vipps, it is safe to restart it. If you get a timeout here, it is *probably* not 100% safe to continue. Same with a 500; though those are very rare. These should throw exceptions at this point though, so printing an error message should be ok.
2. At this point you know that the previous Vipps session of this order is dead, so you should mark the order with the “next iteration” and remove the _vipps_init_timestamp and _vipps_orderurl metas. _vipps_status should probably be set to INITIATED. You can then indeed modify the woo_vipps_orderid filter, and for orders marked like this, our plan is to add (and increase, as neccessary) a *suffix*. That is, the normal vipps orderid is <prefix> . <orderid>; here you will instead return <prefix> . <orderid> . ":" <next suffix>. It should then be possible to restart this order with the new orderid.

For Vipps Checkout, the code will soon have evolved a bit in this direction. These orders start out like Express Checkout, that is anonymous and without shipping; but it is possible (and code we are working on) will shortly add both user information and shipping as soon as this is possible in the checkout window. Then much of the same logic will apply; if it is possible to prove that no browser tab still has the original checkout session open – otherwise these sessions can last for ~1 hour with no interaction.

This is the plan at least; and I apologize that is this complicated. There are three payment APIs involved, and it can be hard to determine if a session is truly dead or just not yet completed. If you have further questions or ideas, please send us an email at [email protected] and we’ll coordinate.

Thank you for those pointers. I was able to get this working. Had to also regenerate the order key, and used “i” insetead of “:” as the suffix number separator for the vipps order id to get it working. Also some special handling to prevent woo-vipps from canceling these orders. It should also hopefully detect when woo-vipps has built in handling of this. I’ll send you the solution if you have any interest in it.

Ok, that’s great! Yes, please send the solution to [email protected] if you have the time.