This guide helps you troubleshoot all the different checkout flows in Dintero Checkout for WooCommerce:

• Checkout Express Embedded
• Checkout Express Pop-out
• Checkout Embedded
• Checkout Pop-out

The Checkout flow in Dintero Checkout is constructed in a way that a WooCommerce order will be created first (in Pending status), then the Dintero 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 Dintero (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.

If you are using Dintero Checkout, you may notice more orders in Pending payment status. This is expected behavior, and happens because WooCommerce can create a pending order as soon as checkout begins – before the customer clicks the “Pay” button. This behavior varies depending on which Dintero checkout flow is used, more information can be found here.

I see pending orders in WooCommerce, is something wrong?

As mentioned above – you can have pending orders in WooCommerce with Dintero 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

The log entries reflect the checkout flow steps and will appear the same regardless of whether the Display Shipping in Checkout Express setting is enabled or disabled.

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. Get access token (POST)

"id":null,"type":"POST","title":"Get access token"

The access token is used for authenticating the merchant, and is required in all API calls. It automatically expires at a known interval specified by Dintero.

This happens whenever the access token expires or when the merchant updates the plugin settings.

2. Create Dintero session (POST)

"id":"dintero-order-id","type":"POST","title":"Create Dintero session."

When customers visit the checkout page, a new checkout session is initiated. This action generates a fresh Dintero session ID that will be linked to the on-going session.

This event should happen only once.

3. Update Dintero Session (PUT)

"id":"dintero-order-id","type":"PUT","title":"Update Dintero Session."

Whenever a change occurs in WooCommerce, we need to notify Dintero about it. We achieve this by issuing a PUT request. 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 Dintero about these changes.

This usually happens more than once.

4. Frontend JS – Validating session

"Frontend JS : dintero-order-id | Validating session with id: dintero-order-id"

The customer data, and the cart data was submitted to WC for validation.

This event can happen more than once if the cart is modified or if/when the customer clicks on the place order button again after a previous check failed. In case the cart was modified, and a pending order has already been created, it will be re-used (i.e., no new order will be created).

5. Get Dintero session (GET)

"id":"dintero-order-id","type":"GET","title":"Get Dintero session."

Between the time the customer is redirected from the checkout page to the thank-you page, we need to check if any changes have happened at Dintero. For this reason, we issue a GET request to Dintero. For example, whether the order has the expected order status, or if we need to take into account a different order status.

This happens as often as “validating session” has to happen.

6. Frontend JS – Order submitted successfully

"Frontend JS : dintero-order-id | Order ID wc-order-id | Order submitted successfully."

The customer data is valid, the cart data is valid, and a pending payment WC order was created successfully.

This event can happen more than once if the cart is modified or if/when the customer clicks on the place order button again after a previous check failed. In case the cart was modified, and a pending order has already been created, it will be re-used (i.e., no new order will be created).

7. Redirect to Thank-You Page

"REDIRECT [success]: The WC order id: wc-order-id (transaction ID: dinero-order-id) was placed successfully. Redirecting customer to thank-you page."

The purchase has been processed successfully by Dintero. At this point, the customer will be redirected to a custom page where we check for if all the necessary data for verifying the WC order exist. This data is included in the redirect URL that Dintero provides. If the data is in place, the customer is redirected to the confirmation (thank-you) page. Otherwise, they’re redirected back to the checkout page.

In case of an error, the customer is redirected back to the checkout page with the following error notice: “Something went wrong with completing the order. Please try again or contact the store”.

For troubleshooting, check for any “REDIRECT ERROR” entries in the plugin’s log. A reason will also be written to the WC order as an order note.

This should happen only once.

8. Update Dintero Transaction (PUT)

{"id":"dintero-order-id","type":"PUT","title":"Update Dintero Transaction."}

The Dintero merchant reference is updated with the WC order number.

This happens only once.

9. Get Dintero order (GET)

"id":"dintero-order-id","type":"GET","title":"Get Dintero order."

The Dintero transaction data is retrieved to verify the integrity of the WC order, and additional metadata. This metadata includes, but is not limited to the environment (test or production), payment token for subscription, the transaction ID, and organization number (if applicable).

In case of missing metadata that otherwise included in similar orders, check for this GET request in the log.

This happens only once.

10. Callback triggered by Dintero

"CALLBACK: Callback triggered by Dintero. Data:...”

The store has received a server-to-server call (a “callback”) from Dintero containing information about the state change of a transaction (corresponds to a WC order). This callback will be scheduled for later processing (within 60  seconds) if not already scheduled.

For troubleshooting, check for any “CALLBACK ERROR” entries in the plugin’s log.

This event usually happens more than once. However, if the store doesn’t respond to Dintero, Dintero will send another callback request.

11. Callback – Handling AUTHORIZED order status

"CALLBACK: Handling AUTHORIZED order status. Maybe triggering payment_complete. WC order id: wc-order-id (transaction ID: dintero-order-id)."

An authorized transaction will be processed for payment complete. This is a fallback in case a successful purchase was not properly processed by the store. If already processed properly, no further processing will happen.

This happens only once.

12. Get Dintero order (GET)

"id":"dintero-order-id","type":"GET","title":"Get Dintero order."

This is part of the authorized transaction processing. A request to retrieve the most up-to-date information about the transaction is sent. This information will be used for verifying the integrity of the WC order, and potentially, adjust or add any missing information.

This happens as often as “Handling AUTHORIZED” happens, which is typically only once.

13. Order Management – Capture Dintero order

"id":"dintero-order-id","type":"POST","title":"Capture Dintero order."

A request to capture the corresponding transaction for the given WC order is sent to Dintero.

This should happen once .

14. Order Management – Callback triggered

"CALLBACK: Callback triggered by Dintero. Data:...”

This callback is part of order management, and is intended for keeping the WC order in sync with the Dintero transaction’s new status. Similar to previous callback handling, this too is scheduled for later processing.

Note: depending on the transaction status, its processing differs. For “authorization” and “captured” refer to 11 (above).

• “authorization_voided” (cancelled): the order status is updated to “cancelled”.
• “declined” or “failed”: the order status is updated to “failed”.
• “refunded”, and other [unknown] status: nothing will happen, but the event will be logged.

This happens as often as the Dintero transaction’s status changes to any of the above statuses.

15. Order Management – Callback Handling CAPTURED order status

"CALLBACK: Handling CAPTURED order status. Maybe triggering payment_complete. WC order id: wc-order-id (transaction ID: dintero-order-id)."

For Swish payment, the authorization callback described above under “Callback triggered” isn’t used. Instead, a “captured” event is received by the store. Since we also need to account for issues that may occur during a Swish payment, the same steps as in the “Handling AUTHORIZED order status” section is performed:

• The Dintero transaction data is retrieved (GET request) to verify the integrity of the WC order, and additional metadata. 
• This metadata includes, but is not limited to the environment (test or production), payment token for subscription, the transaction ID, and organization number (if applicable). In case of missing metadata that otherwise included in similar orders, check for this GET request in the log.

This event is also triggered when a transaction is captured either through the Dintero backoffice or the WC store. However, in practice, it won’t affect the order since it has already been processed.

Other Order Management logs

The log entries in the Order Management logs look the same, regardless of which Dintero checkout flow you use.

Cancel an order

1. Get Dintero order (GET)

"id":"dintero-order-id","type":"GET","title":"Get Dintero order."

This request is issued to retrieve the most up-to-date transaction status to avoid errors such as attempting to cancel a transaction that is in a non-cancellable state (e.g., already cancelled).

This happens only once.

2. Cancel Dintero order (POST)

"id":"dintero-order-id","type":"POST","title":"Cancel Dintero order."

A request is sent to Dintero to cancel the transaction. The response indicates whether the request was successful or failed.

Note: for Swish payments, a refund is issued instead (refer to “Refund Dintero order (POST)” in the “Refund an order” section). However, the order note will still say,”The Dintero order has been canceled”.

This happens only once.

3. Order Management – Callback

"CALLBACK: Handling AUTHORIZATION_VOIDED order status. Setting order status to CANCELLED. WC order id: wc-order-id (transaction ID: dinero-order-id)."

The transaction will be processed for cancellation. This is ignored unless the cancellation wasn’t processed in the previous cancellation request.

This happens only once.

Refund an order

1. Get Dintero order (GET)

"id":"dintero-order-id","type":"GET","title":"Get Dintero order."

This request is issued to retrieve the most up-to-date transaction status to avoid errors such as attempting to cancel a transaction that is in a non-refundable state (e.g., already refunded or not yet captured).

This happens only once.

2. Refund Dintero order (POST)

"id":"dintero-order-id","type":"POST","title":"Refund Dintero order."

A request is sent to Dintero to refund the transaction. The response indicates whether the request was successful or failed.

This happens only once.

Callback

1. Callback triggered by Dintero

"CALLBACK: Callback triggered by Dintero. Data:...”

The store has received a server-to-server call (a “callback”) from Dintero containing information about the state change of a transaction (corresponds to a WC order). This callback will be scheduled for later processing (within 60 seconds) if not already scheduled.

For troubleshooting, check for any “CALLBACK ERROR” entries in the plugin’s log.

This happens only once.

2. Callback – action_scheduler

"CALLBACK [action_scheduler]: The merchant reference your-merchant-reference and transaction id dinero-order-id has already been scheduled for processing."

A check for whether the received callback should be scheduled for later processing. Since the callback has already been scheduled in a previous callback, the callback will be ignored.

Note: A callback is considered “scheduled” if it has been scheduled within the last 60 seconds, and if the merchant reference, and the transaction ID included in the callback matches the existing scheduled callback.

This happens only once.

3. Callback – Partially refunded order

"CALLBACK: Unknown order status on callback: PARTIALLY_REFUNDED. WC order id: wc-order-id (transaction ID: dintero-order-id)"

This callback is ignored, but the event will be logged.

This happens every time the order is partially refunded.

4. Callback – Fully refunded order

"CALLBACK: Handling REFUNDED order status. WC order id: wc-order-id (transaction ID: dintero-order-id)"

This callback is ignored, but the event will be logged.

This happens only once.

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.

WooCommerce Subscriptions and recurring orders

Recurring token

If the cart contains a subscription, a recurring token, also known as a payment token, will be generated when the checkout process is completed as a part of the order confirmation step.

The recurring token will be returned in the GET request proceeding the “Update Dintero Transaction” request, and saved to the WC order, and its related subscription. The keyword to search for in the log is payment_token. This behavior is consistent across checkout flow. The only difference is that if the cart doesn’t contain a subscription, the payment token will not be included in the GET request’s response.

Manage Subscription

When handling the subscription order via My account as a customer or via backend as an administrator, for example Suspend, Cancel, Reactivate or Change address on the subscription, nothing will be logged.