WooCommerce store billing and invoicing
09/11/2026

Research and practical tests for fast checkout and correctly documented payment
A customer adds a product to their cart, selects a delivery, and enters payment information. For the purchase to be successful, the store needs to display the correct amount, respond to their actions, receive payment confirmation, and update the order. Then, the appropriate document needs to be generated. A glitch in any of these steps can leave the business owner with an order that they are unsure of how to handle.
Store owners and those who set them up should check this sequence before launching the site and also after changing the checkout plugin, template or storage. The studies explain why the checkout deserves attention; tests with a defined result make it possible to discover what needs to be fixed in the store itself.

Illustration of placing an order in an online store
What the research teaches about checkout abandonment
In a survey updated in October 2026, the Baymard Institute presents an average cart abandonment rate of 70.22%. This is an unweighted average of 50 studies from 2006 to 2025, with differences in markets and measurement methods. It describes a broad phenomenon, and is not an Israeli index or a forecast for a specific store.
Alongside the review, Baymard is publishing findings from a survey of shoppers in the United States. 17% reported abandoning an order due to a reason the institute phrased, translated from English, as follows: “The checkout process is too long or complicated.” Browsing without the intention of purchasing is also a significant reason for abandonment. Therefore, not all abandoned carts should be attributed to a technical glitch.
The implementation in the store is simple: display the shipping cost and final amount as early as possible, remove unnecessary fields, and try to complete the purchase as a guest, if the store allows it. Document where the buyer is required to stop, correct information, or return to the previous page. This way, you can separate a difficulty at the checkout from a lack of interest in the product.
Measure speed instead of just feeling it
The 2020 Milliseconds Make Millions report, prepared by Deloitte based on analysis by Fifty-Five and commissioned by Google, examined mobile data from 37 brands in Europe and the United States over four weeks. The retail site group reported an 8.4% relative increase in conversions, which was linked to a tenth of a second improvement in four speed metrics examined together. The report states, translated from English: “Improvements in mobile site speed were found to be directly correlated with progression through the purchase funnel.”
This is an observational study of brand websites, based on a statistical model and natural speed fluctuations. It is not an experiment that guarantees additional sales for every store, and it does not test a storage upgrade alone. The practical conclusion is to measure the mobile shopping experience, identify what slows it down, and examine the result after correction.
For ongoing monitoring, you can use Google’s Core Web Vitals metrics. The goals for a good experience are an LCP of up to 2.5 seconds for displaying the main content, an INP of up to 200 milliseconds for responding to actions, and a CLS of up to 0.1 for display stability. The 75th percentile of the data is examined, separately for mobile and computer. A lab test in the PageSpeed Insights tool is useful for diagnosis, and actual user data reflects the experience on the site.
Measure the product page, cart, and checkout, and also record the time of quantity change, coupon application, and shipping selection. When contacting the hosting company, include the page address, time of testing, and the delayed action. This information helps them examine the relevant server request and determine whether the source is in the server resources, a plugin, or an external service.
Define a cache that suits the store
Page caching keeps a ready copy to save work on each visit. The checkout page displays details that vary based on the customer and their cart. The official WooCommerce documentation states that the shopping cart, checkout, and customer account pages should be excluded from page caching. The explanation, translated from English, is: “These pages should remain dynamic, as they display information unique to the current customer and their cart.”
Check with your hosting company that the exclusions also apply to the cache on the server or content distribution network, if any, and to the cache plugin on the site. Then open two separate browsing windows, add different products, and make sure each cart remains independent. Change the address, shipping method, and coupon, and check that the amount is updated. This check can reveal old information that is being served to the buyer even when the page loads quickly.
Verify payment even when the customer closes the browser
After payment, the customer may close the tab before returning to the store. The thank you screen alone is not enough to determine whether the money was received. The WooCommerce documentation also describes server updates from payment providers, called callbacks, which allow the payment gateway to update the order status. When choosing a plugin, ask how it verifies the payment and how it detects a transaction whose update has been delayed.
In the event of a charge report without an updated order, look up the order number and transaction ID with the payment provider. Check the confirmation and amount before manually changing or requesting another payment. If the provider has confirmed a payment but the document has not yet been generated, the generation should be handled without creating an additional charge. Before manually generating, also look for an existing document for the same transaction.
Attach the invitation to the business document
Let’s say the customer bought products for 240 NIS, received a 20 NIS discount, and paid 30 NIS for shipping. Assuming the prices include the applicable tax and there are no additional components, the amount to be paid is 250 NIS. This is the amount that needs to be reconciled between the cash register, the payment confirmation, and the document. The comparison should also include the customer details and the order components, so that it can be explained how the amount was received.
For example, Daily for online stores offers a WooCommerce plugin that connects order payment to document creation after full and verified approval, according to the business settings. You can simulate approval and rejection at a checkout without charging and without generating a financial document. This test helps to test the behavior of the store; after which a controlled test of the live payment path is also required. The installation and testing guide details the steps.
Before starting, choose the type of document with your accountant or tax advisor, depending on the business and the documents that have already been produced. The scope of the connection also requires clarification: producing a document does not in itself indicate inventory synchronization between the systems. Quantity management and returns must be defined and checked separately.
Plan your refund treatment in advance
According to WooCommerce documentation, changing the status to a canceled or refunded order does not automatically issue a refund. Automatic refunds from within the order depend on the payment gateway’s support; manual refunds in the interface document the action, and also require a refund outside of that interface. Before you start selling, define who issues the refund and how their credentials are stored.
In the Daily connection described in this guide, the refund is processed through the payment provider, and the document is handled separately. The WooCommerce Documentation Guide details the process. Even with a partial refund, there must be a link between the order, the amount refunded, and the corresponding document, so that whoever is handling the customer can see what has already been done.
Checklist before opening the cash register
The table can be used as a shared acceptance test for the business owner and the website maintainer. Start in a separate environment that is not open to buyers, as per the plugin and payment provider instructions. A no-charge simulation only tests part of the process; a live path is tested separately and in a controlled manner. Keep a result and order number for each scenario.
| scenario | What are you checking? | Desired result |
| Mobile purchase | Complete a purchase on a real device, including choosing delivery. | The fields and buttons are accessible and the final amount is clear before confirmation. |
| Coupon and shipping | Compare the price after discount and additional shipping. | The same amount appears on the order, the invoice, and the live transaction document. |
| Separate baskets | Use two browsers or separate windows. | Each buyer has an independent basket, without products or amounts from the other check. |
| Payment rejected | Simulate a rejection in the way that the payment provider or plugin allows. | A clear message is displayed; the order is not being treated as a confirmed payment. |
| Closing browser | In a supported test scenario, close before returning to the store. | You can check the payment with the supplier and the order without relying on a thank you page. |
| Back to the thank you page | Refresh the page after a suitable test transaction. | The refresh does not create an additional charge or duplicate document. |
| Partial refund | Check the supported track and the required documentation. | The refund amount, vendor reference, and linked document are searchable. |
| Website change | After updating a plugin or storage, the critical scenarios repeat. | The results remain intact and the required settings have been saved. |
Checking if the change helped
Before and after a fix, compare periods with similar traffic. Track the rate of visitors who start a checkout and complete a purchase, separate mobile from desktop, and also count failed payments and approved transactions with pending documents. Keep the same measurement setup: A change in devices, traffic sources, or campaign can explain some of the difference. Start with one documented issue, fix it, and then go back to the same test.
