Get started
Customization
- Home
- /
- Avarda Checkout for WooCommerce
- /
- Troubleshooting
- /
- Troubleshooting the recurring payments flow
Troubleshooting the recurring payments flow
The Checkout flow in Avarda Checkout is constructed in a way that a WooCommerce order will be created first (in Pending status), then the Avarda 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 Avarda (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 Avarda Checkout 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. Loading checkout template for Avarda
"Loading checkout template for Avarda checkout because ACO is the chosen method: template-url"
The checkout template is replaced by Avarda’s embedded checkout since the customer chose Avarda as a payment method.
This event will happen every time the checkout page is visited when Avarda is the chosen payment method.
2. No purchase ID found
"No purchase id found in order or session when getting Avarda Payment."
The existing session doesn’t contain a purchase ID. How we handle this differs depending on the context, but most likely we’ll create a new session. If this keeps happening persistently, there might be an issue with the WooCommerce session management (most likely caused by a third-party plugin or the hosting provider).
This event can happen more than once.
3. ACO create auth token (POST)
"id":"","type":"POST","title":"ACO create auth token"
The auth token has expired, and we’ve requested renewal.
This event happens every time the auth token expires (typically every 55 minutes).
4. ACO initialize payment (POST)
"id":"","type":"POST","title":"ACO initialize payment"
When customers visit the checkout page, a new checkout session is initiated. This action generates a fresh Avarda order ID that will be linked to the ongoing session.
This event should happen once.
5. ACO get payment (GET)
"id":"avarda-order-id","type":"GET","title":"ACO get payment"
This request is made whenever Avarda notifies us about a change that occurred in the embedded payment form. We need to retrieve the updated form data from them in such cases. It’s important to note that this type of request can occur multiple times.
For instance, when a customer enters the billing address in the embedded payment form and clicks on the “Continue” button can be a trigger for this event.
State: Initialized
This event can happen more than once.
6. ACO update payment (PUT)
"id":"Avarad-order-id","type":"PUT","title":"ACO update payment"
Whenever a change occurs in WC, we need to notify Avarda about it. We achieve this by issuing a PUT request. It’s important to note that this type of request can occur multiple times, and the changes made may not always be immediately reflected in Avarda’s embedded payment form.
For instance, if a new item is added to the cart or if the quantity of an item is modified, a PUT request is sent to inform Avarda about these changes.
This event can happen more than once.
7. ACO get payment (GET)
"id":"avarda-order-id","type":"GET","title":"ACO get payment"
Same as step 5 but with another state.
State: InProcess
This event can happen more than once.
8. Received “beforeSubmitCallback” from Avarda
"Frontend JS avarda-order-id: Received \"beforeSubmitCallback\" from Avarda"
When the customer submits the order, Avarda will inform us of this event. At this point, we’ll request from WooCommerce to create a new “pending payment” order, and if this is successful, we’ll inform Avarda to proceed with the order. Otherwise, we’ll inform Avarda to abort the order submissions, which results in a customer-facing error.
This event usually happens once, but can happen multiple times if the order creation described above is unsuccessful or if the WooCommerce cart is modified.
9. Get Avarda purchase ID from session
"Get Avarda purchase ID from session. Order ID wc-order-id. Avarda purchase ID: avarda-order-id"
The expected behavior is that the session ID as received during the session initialization should remain consistent throughout the checkout process. This piece of information is useful to identify whether an existing session had been reset. A session reset is unusual, but this log entry is useful for indicating that there is an underlying problem.
This event can happen more than once.
10. Redirecting to confirmation page
"Processing order wc-order-id|wc_order_xxx (Avarda ID: avarda-order-id) OK. Redirecting to confirmation page."
WooCommerce has processed the order successfully. We’ll now inform the client to redirect the customer to the confirmation page.
This event should happen only once.
11. Confirm the Avarda order from the confirmation page
"avarda-order-id: Confirm the Avarda order from the confirmation page. Order ID: wc-order-id"
A request to redirect the customer was received. We’ll perform additional checks to confirm that the order matches Avarda before updating the order status as payment complete or to on-hold if the checks fail. In either case, the session will be purged, and the customer is finally redirected to the confirmation page.
This event should happen only once.
12. Notification callback hit (Callback)
"Notification callback hit for Avarda purchase ID: avarda-order-id. WC order ID: wc-order-id"
A server-to-server call always happens after the order in the Avarda is completed. This is to ensure that an order is still created in case an unrecoverable error occurred during checkout or if the customer closed the store page abruptly after confirming their purchase. You’ll always see this callback hit regardless of the outcome: whether the order was successful or not.
This event should happen only once.
13. Scheduling notification callback
"Scheduling notification callback to be handled in 2 minutes for Purchase ID avarda-order-id. Order wc-order-id (order ID wc-order-id)."
This event will happen at least once, and every time a callback is scheduled.
14. ACO get payment (GET)
"id":"avarda-order-id","type":"GET","title":"ACO get payment"
Same as step 5 but with another state.
State: Completed
This event can happen more than once.
15. ACO update order reference (PUT)
"id":"avarda-order-id","type":"PUT","title":"ACO update order reference"
Throughout the order process, the Avarda has been having a temporary order number. At this step, now that we have a successful order, we’ll send its order number to Avarda so that they can update the corresponding order in their system.
This event should happen only once.
16. Execute purchase completed API callback (Callback)
"Execute purchase completed API callback. Purchase ID:avarda-order-id. Order ID: wc-order-id"
Executing a scheduled callback.
This event will happen every time a scheduled callback is executed.
17. Aborting purchase completed API callback (Callback)
"Aborting purchase completed API callback. Order wc-order-id(order ID wc-order-id) already processed."
While executing the scheduled callback, we found that the order has already been processed correctly. No further processing is required.
This event can happen more than once.
18. Order Management – ACO get payment (GET)
"id":"avarda-order-id","type":"GET","title":"ACO get payment"
While managing an order, we need to verify its state. Accordingly, we issue a GET request to Avarda to retrieve its current state.
State: Completed
This event can happen more than once.
19. Order Management – ACO activate order (POST)
"id":"avarda-order-id","type":"POST","title":"ACO activate order"
An activate order request is sent to Avarda to request them to capture the order. The response of this request indicates whether the capture was successful.
This event will happen every time the order is set to “Completed” until it has been verified as captured. At that point, a lock will be set to prevent this request from being issued again.