Page Comparison

...

1. Purchase button is clicked. For RCOv2 we use $ResursCheckout.onSubmit().  From that point we call, by ajax, resursbank_checkout_create_order. For RCOv1 it works similarly but with another click-checker based on message events beween the main window and the iframe.
2. resursbank_checkout_create_order resides in src/Module/PluginApi.php but in the API class it has been created with a camelCase transformed method: checkoutCreateOrder().
3. checkoutCreateOrder() stores customer data in session as we are at this moment outside the WooCommerce flow.
4. At first, checkoutCreateOrder() is firing up self::getPreparedRcoOrder() where customer data is collected and handled. In this feature we are discovering whether RCOv1 or RCOv2 is used. Secondly, this function also renders proper POST-data for WooCommerce to use.
5. Secondly, self::getCreatedOrder() is firing up. At this moment we are about to hand over the order to WooCommerce again. This is done by marking the session with order_awaiting_payment as the order still needs a payment.
6. Thirdly, from getCreatedOrder() we are now firing up the last step at the front-end handler: $order->process_checkout(). This function contains an extra layer for the frontend scripts to handle if something goes wrong.
   Note: If this was simplified hosted flow, this process has already been running at step 1-2 (see the other flow above).
7. At this moment, we no longer have responsibility for the order, until WooCommerce executes our plugin's internal process_payment() again. In simplified and hosted flow, this part of the plugin is always executed before Resurs Bank order creation.
   If you check the illustrations here, you You are now at the last step of succession.
   

8. Now we're back in process_payment() again. At this moment, there are still metadata missing for the order, since the creation process is very much reverse. The first steps is about asking WooCommerce to create and handle an order, from which we later can achieve an order id.
   
   So, since the order are already handled by Resurs Bank, most of this section can now be skipped. For example, this is the first moment that we as above said, can get use of a real order id. Therefore most of the data- and metas is now filling in the missing gap of information. The the plugin prepares a success- or failurl return to pass over - to someone. For this flow this data is no longer handed over too WooCommerce entirely. This part matches mostly step 4 in simplified/hosted flow description. So let's head to step 9 to see how the urls are handled.

   Code Block
   language php theme Emacs title RCO vs regular flows collapse true
   if (Data::getCheckoutType() !== ResursDefault::TYPE_RCO) { $return = $this->processResursOrder($order); } elseif (Data::getCheckoutType() === ResursDefault::TYPE_RCO) { // Rules applicable on RCO only. $return['result'] = 'success'; $return['redirect'] = WC_Payment_Gateway::get_return_url($order); }

   
   

9. The final moment in the long procedure has now a catch.
   Since we are now running through a RCO-iframe process, the response created to WooCommerce will actually never reach the regular internal flow properly. At least, this data will never reach the browser, the same way as in the normal flows. It is instead handed over to the Resurs Checkout front-end scripts in the browser, where we can now tell the iframe that we are finally done with our parts. The rest of the purchase process is up to Resurs Bank. When the order is processed at Resurs Bank, the same success and fail-url is now instead handled by Resurs Bank. Therefore Resurs Bank is instead responsible for redirecting the customer back or further to a payment provider or bank signing. When this is done, Resurs Bank returns the customer either to the "Thank you"-success page or a "customer failed/cancelled the payment"-page.

...