Get started
Customization
- Home
- /
- Qliro One for WooCommerce
- /
- Troubleshooting
- /
- Troubleshooting the checkout flow
Troubleshooting the checkout flow
The Checkout flow in Qliro One is constructed in a way that a WooCommerce order will be created first (in Pending status), then the Qliro order is placed, and finally the WooCommerce order is updated to Processing status. This flow is more compatible with other WooCommerce plugins.
This checkout flow also means that Pending orders can be visible in WooCommerce, where the payment has not been finalized in Qliro (for example card payment where there was not enough funds on the card). This is part of the general WooCommerce checkout flow, and it does not implicate that something is wrong.
I see pending orders in WooCommerce, is something wrong?
As mentioned above – you can have pending orders in WooCommerce with Qliro One as the payment method without any errors in your store. These might just be orders not finalized by the customer.
However, if you want to troubleshoot this a bit closer, here’s how you do it.
- Make sure that you have turned on Logging in the plugin settings.
- The logs can be found by navigating to WooCommerce → Status → Logs.
Order creation step by step
Order creation step by step and how to debug and follow it in the log
Some of these events happen one time in the order creation, while others can happen multiple times. We have added a note to each event on whether you should expect to find it in the log once or several times.
1. Create order (POST)
"id":qliro-order-id,"type":"POST","title":"Create order - URL: customer-url”
When the customer first visits the checkout page, a new Qliro checkout session is created. This session will remain, and will be re-used until it has been cleared. Along with the session, a Qliro order ID is created to identify this specific session.
This event should happen once.
2. Get order (GET)
"id":qliro-order-id,"type":"GET","title":"Get order - URL: customer-url"
When the checkout is updated we’ll issue a GET request to Qliro. The response contains the current Qliro session status that we’ll use to verify that the WooCommerce session (or order) is consistent with the Qliro. In other instances, we use the response to determine whether we need to take further actions to ensure consistency between the systems.
This event can happen multiple times.
3. Update order (PUT)
"id":qliro-order-id,"type":"PUT","title":"Update order - URL: customer-url"
When a change happens in WooCommerce, we need to update the Qliro session to ensure the systems are in sync. For this reason, we’ll issue a PUT request to Qliro containing the changes.
For example, if a new item is added to the cart or if the quantity of an item is modified, changed delivery information or changed billing details, a PUT request is sent to inform Qliro about these changes.
This type of request can occur multiple times, and the changes made may not always be immediately reflected in Qliro’s embedded payment form.
This event can happen multiple times.
4. onValidateOrder from Qliro triggered
"Frontend JS “qliro-order-id”: onValidateOrder from Qliro triggered"
When the customer clicks the Complete Purchase button within the Qliro payment form (the “iframe”), Qliro will send a request to our client to validate the WooCommerce session before proceeding with the purchase. When this request is received, we’ll write this message to the log.
This event will happen every time the customer clicks on the purchase button. Usually, this should happen only once.
5. Successfully placed order
"Frontend JS “qliro-order-id”: Successfully placed order. Sending \"shouldProceed: true\" to Qliro."
The WooCommerce session was validated, and no issue was identified. A pending payment WC order was successfully created. Qliro can now proceed with the purchase.
This event can happen more than once if the customer for example cancels the purchase in a later state of the checkout process, returns to the store to add another product and then proceeds to the checkout again etc. It will happen every time Qliro needs to validate the WC session state.
6. Checkout Callback received
"Checkout Callback recieved: {\"Status\":\"Completed\",\"NotificationType\":\"CustomerCheckoutStatus\",\"OrderId\":qliro-order-id
When the customer purchase has been completed in the Qliro payment form, and an order is created in Qliro’s system, Qliro will inform us about this through a “callback”. Since this is a server-to-server call, it is intended to capture any failures between the customer and WC store. For example, if the customer was not redirected to the confirmation page, this callback will let us know that the Qliro order was completed, so the WC order should be updated accordingly.
This message is logged when a callback is received.
This event should happen once.
7. Scheduling completed checkout callback
"Scheduling completed checkout callback for order with confirmation_id your-confirmation-id."
To avoid overwhelming the WC store, and prevent state inconsistencies, the received callback will be scheduled for later processing, 2 minutes later.
This message is logged when the callback is successfully scheduled. If the received callback was not, most likely, the corresponding WC order that the callback concerns couldn’t be found or something else went wrong.
This event should happen once.
8. Get order ( admin ) (GET)
"id": qliro-order-id,"type":"GET","title":"Get order ( admin ) - URL: customer-url”
Same functionality as step 2 but this log happens after the order has been created or after the order confirmation step.
This event can happen more than once.
9. Update merchant reference (POST)
"id": qliro-order-id,"type":"POST","title":"Update merchant reference
Once the WC order has been created, WC will assign it an order number. This is the number that the WC store uses to identify the order, and what the customer should refer to. For this reason, we send this update request to Qliro so that they may include it in their payment system.
This event should happen once.
10. Confirmed on the confirmation page
"Order ID wc-order-id confirmed on the confirmation page. Qliro Order ID: qliro-order-id."
Qliro has informed us that the purchase was completed in their system, and we may now redirect the customer to the thank-you (confirmation) page. This event indicates that this redirect has happened, and that we’re now performing additional checks (“confirmation checks”) to verify the integrity of the WC order.
This should also clear the session, allowing the customer to create a new order. If the session isn’t properly cleared, this event may happen more than once.
This event should happen once.
11. Aborting qliro_confirm_order function
"Aborting qliro_confirm_order function. WooCommerce order wc-order-id already confirmed."
Before we perform any confirmation checks (see step 10 above), we need to make sure that the order has not already been confirmed. If that is the case, this event will happen.
This event might happen more than once, for example, if the customer was not properly redirected from the checkout page.
12. Execute completed checkout callback
"Execute completed checkout callback for order with confirmation_id your-confirmation-id."
Executes the callback that was scheduled earlier (see step 7 above). This event confirms that the schedule has happened, but it doesn’t indicate that it was processed successfully.
A failed execution is indicated by “Could not find an order with the confirmation ID ”.
This event should happen once.
13. Order Management – Capture order (POST)
{"id": qliro-order-id,"type":"POST","title":"Capture order - URL: customer-url"
The order status in WC was set to “Completed”. We’ll issue a request to Qliro to update the order status to “Capture” in their system.
This event should happen once.
14. Order Management – Callback received
"OM Callback recieved: {\"Status\":\"Success\",\"OrderId\": qliro-order-id”
A callback was received from Qliro concerning the status change of a Qliro order.
This event should happen once.
15. Order Management – Processing capture callback
"Processing capture callback for order wc-order-id."
The received callback concern a capture request. That is, an order whose status was updated to “Capture”, typically as a result from the capture order request mentioned earlier (see step 14 above).
This event should happen once.
Order management logs
Cancel an order
1. Cancel order (POST)
{"id": qliro-order-id,"type":"POST","title":"Cancel order - URL: customer-url"
The order status in WC was set to “Cancelled”. We’ll issue a request to Qliro to update the order status to “Reversal” in their system.
2. Callback received
"OM Callback recieved: {\"Status\":\"Success\",\"OrderId\": qliro-order-id”
A callback was received from Qliro concerning the status change of a Qliro order.
3. Processing cancel callback
"Processing cancel callback for order wc-order-id."
The received callback concerning a cancel request. That is, an order whose status was updated to “Reversal”, typically as a result from the cancel order request mentioned earlier.
Refund an order
1. Return items (POST)
{"id": qliro-order-id,"type":"POST","title":"Return items - URL: customer-url"
The order status in WC was set to “Refunded” (wholly or partially). We’ll issue a request to Qliro to update the order status to “Refund” in their system.
2. Callback received
"OM Callback recieved: {\"Status\":\"Success\",\"OrderId\": qliro-order-id”
A callback was received from Qliro concerning the status change of a Qliro order.
3. Processing refund callback
"Processing refund callback for order wc-order-id."
The received callback concerning a refund request. That is, an order whose status was updated to “Refund”, typically as a result from the refund order request mentioned earlier.
Errors that might happen
1. Checkout error
If the order creation didn’t go as expected you might see a Checkout error. This is caused by WooCommerce validation NOT being successful (e.g., coupon errors, subscription that require login, no stock, timeout).
2. AJAX error
If the order creation didn’t go as expected you might see a AJAX error in the log. If you see the AJAX error you need to talk to your developer or the support. This is most likely caused by a third party plugin, or other code.
Other log messages you can see
1. Handles the Order Management push callback:
"Unhandled callback for order qliro-order-id. Callback type: {$status}"
We received a callback from Qliro with an unsupported status change. This should never happen, and only exists as a default.
2. Handles the Checkout push callback:
"Scheduling refused callback for order with confirmation_id your-confirmation_id."
"Scheduling onhold callback for order with confirmation_id your-confirmation_id."
"Unknown Qliro One checkout callback status: {$data['Status']}"
A callback was received, we’ve scheduled an event for each of these status changes, unless it is unknown. In that case, the callback will be ignored.
3. Process the successful callback from the checkout push:
"Could not find an order with the confirmation id your-confirmation_id when completing the checkout"
The confirmation ID didn’t match any WC order. Most likely, somewhere between the checkout and confirmation steps something went wrong.
4. Confirm a Qliro order:
"Failed to get the admin order during confirmation. Qliro order id: qliro-order-id, WooCommerce order id: wc-order-id"
This is part of the confirmation checks (see step 10 in the Order creation above). We could not retrieve the Qliro order for some reason. This could be due to a network issue or no Qliro order with this specific ID could be found, or something else.