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

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 should happen only once.

3. 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.

4. 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.

5. 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 should happen only once.

6. 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.

7. 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.

8. 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.

9. 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 if the capture was successful. Otherwise, you may see multiple capture requests until at least one is successful or capture is no longer possible for some reason.

10. 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.

11. 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.