# Slow Checkout

Checkout is slow when your store is slow to answer the till. A sale waits for your store twice: when you press **Checkout**, the order is saved to your store, and when you press **Take**, your store records the payment before the receipt shows. This page shows where the till waits, how to measure your store, and what to change.

Cashiers: measure, then hand over

The fixes are made on your website, mostly in WP Admin. If you don't run the website, [time a test sale](#time-a-sale) and send the times, with a link to this page, to whoever does.

## Time a test sale[​](#time-a-sale "Time a test sale으로 직접 링크")

Time a test sale before and after each change to see what it buys you. Each count is time the till spends waiting for your store:

1. Count from **Checkout** until **Take** stops reading **Saving order…**.

2. Pay, and count the wait for the way you paid:

   <!-- -->

   * **Cash, Card or another payment recorded at the till** — from **Take** until the receipt shows.
   * **A card reader** — from tapping its tile until it reaches **On terminal**, then again from **Approved** until the receipt shows. Leave out the time the customer spends at the reader.
   * **The Legacy tab** — from opening the tab until **Process Payment** can be pressed.

3. Note the **typical response** from [Store health → Performance](#store-health).

Repeat step 2 for each way you take payment, and change one thing at a time between tests. [Where the till waits](#where-it-waits) explains what each count measures. Time it on the device and connection you sell on: another device or network can give different times.

## Where the till waits for your store[​](#where-it-waits "Where the till waits for your store으로 직접 링크")

**Checkout** — the order is saved to your store. The checkout opens at once, but the keypad doesn't respond and **Take** reads **Saving order…** until your store answers. After 4 seconds a message says the store isn't answering: see [what to do](#store-not-answering).

**Take**, on Cash, Card or another payment recorded at the till — your store records the payment, and then the receipt shows. If your store doesn't answer, the till asks again after 1, 3 and 9 seconds. If it still has no answer: see [what to do](#payment-not-answered).

**A card reader tile** — your store creates the payment first. Then the tile reaches the **On terminal** step and reads **Waiting for the customer on the terminal**, or **Present card on the reader** on a reader connected straight to this till. If the till keeps failing to reach your store while it waits, the tile keeps that message, and its **Details** log adds **Connection unstable, still trying**. Once the reader approves, the tile shows **Approved** while your store confirms the payment, and then the receipt shows. See [Taking a Payment](/ko/sell/take-payment.md#card-reader).

**The Legacy tab** — your store sends its payment page. A loading placeholder shows, and **Process Payment** stays greyed out until the page loads. If it doesn't load: see [what to do](#payment-form-didnt-load). See [The Legacy Tab](/ko/sell/take-payment/legacy-tab.md).

Each wait is a request to your store, so a store that answers slowly makes every sale slow. Offline, a payment recorded at the till doesn't wait: the sale is held on this device and sent when the store is back. See [Offline Mode](/ko/sell/offline-mode.md).

## Measure your store[​](#measure "Measure your store으로 직접 링크")

A test sale times one sale. **Store health** shows how your store has answered this till all day.

### Store health → Performance[​](#store-health "Store health → Performance으로 직접 링크")

**Store health → Performance** shows how fast your store has answered this till over the last 24 hours.

![Store health on the Performance tab: the status line with the typical response time, the hourly uptime strip, the Eco, Balanced and Realtime cards and the two sliders](/img/2.x/support/performance/checkout/en/tablet-light-regular--cp-1-performance.png)1234567

1. **Store health** — the pulse icon near the foot of the menu.
2. **Performance** — this tab.
3. **Status line** — the requests this till made in the last 24 hours, and the **typical response**: how long your store took to answer, on average across all those requests. Compare it with the times from [your test sale](#time-a-sale).
4. **Engine uptime** — one cell per hour. Amber means at least one request to your store failed that hour.
5. **Balanced** — how often this till checks your store for changes. On shared or budget hosting, **Eco** asks less often and leaves your store more room for sales. See [Sync presets](/ko/troubleshooting/store-health.md#sync-presets).
6. **Check for changes** — the same setting as a slider, from 5 seconds to 5 minutes.
7. **Right now** — about how many requests an hour these settings make.

Further down, **Your server, over time** charts your server's load beside the POS's requests. On a till that has just started, both charts read *Not enough data yet* and fill in as the till runs.

Read the server charts

![The lower half of the Performance tab: the pace line, and the Server load and POS requests charts, still empty on a till that has just started](/img/2.x/support/performance/checkout/en/tablet-light-regular--cp-2-server-over-time.png)12345

1. **Right now** — the requests an hour these settings make.
2. **Your server, over time** — the section heading.
3. **Pace** — **Normal pace**, or **Easing off** when your server answered slowly, timed out or returned errors. See [Your server, over time](/ko/troubleshooting/store-health.md#server-load).
4. **Server load** — everything running on your server, not just the POS, with the latest figure on the right. A high figure alone doesn't slow the till down: read it with the **typical response**, and give both to your host.
5. **POS requests** — how many requests this till made each hour.

## Speed up saving and paying[​](#saving "Speed up saving and paying으로 직접 링크")

Check these possible causes one at a time, and [time another test sale](#time-a-sale) after each change.

### Order storage[​](#order-storage "Order storage으로 직접 링크")

If WooCommerce still keeps orders in WordPress posts (legacy storage), every save at checkout gets slower as your store grows. Check which storage you use and switch to HPOS: see [Order Storage (HPOS)](/ko/troubleshooting/performance/order-storage-hpos.md).

### Plugins that run when an order is saved[​](#2-plugin-interference-during-order-creation "Plugins that run when an order is saved으로 직접 링크")

Some plugins do their own work each time an order is saved or paid, and the till waits for them. An accounting plugin that sends the order to Xero, for example, holds every sale until Xero answers. Turning plugins off one at a time on a copy of your website finds the one.

Find the plugin, step by step

Plugins that often do work on every order:

* Accounting and bookkeeping (Xero, QuickBooks)
* Email marketing tools that act on new orders
* Inventory and stock systems
* Shipping calculators
* Analytics and tracking

To find the one:

1. On a [staging site](/ko/troubleshooting/common-problems/plugin-conflicts.md#before-you-start-use-a-staging-site), turn off every plugin except WooCommerce and WCPOS.
2. [Time a test sale](#time-a-sale).
3. If it's much faster, turn the plugins back on one at a time, timing a sale after each, until it slows down again.
4. Ask that plugin's developer whether its work can run in the background instead.

The full method is in [Plugin Conflicts](/ko/troubleshooting/common-problems/plugin-conflicts.md#step-2-the-plugin-elimination-method).

### Your hosting[​](#hosting "Your hosting으로 직접 링크")

If the **typical response** is slow as well as your checkout times, your server may be short of resources. Take the times from [your test sale](#time-a-sale) to your host, with the **Server load** figure, so they can look into it. See [Server Performance](/ko/troubleshooting/performance/slow-server.md) for recommended specifications.

What to ask your host

* CPU and memory use while you sell
* The PHP memory limit and the number of PHP workers
* Slow database queries, and old data that could be cleaned up
* Object caching (test it with the POS before you rely on it)
* A larger plan, or a VPS instead of shared hosting

## Speed up the Legacy tab's payment page[​](#legacy-page "Speed up the Legacy tab's payment page으로 직접 링크")

Only gateways on the **Legacy** tab load a web page at checkout. It's a stripped-down copy of the WooCommerce page customers use to pay for an order online, sent by your website each time. Your theme's header, footer and layout are already gone, but the styles and scripts your theme and plugins add to every page still load, and they can make the page slow or break it. Changing what it loads is a job for a shop manager. If the page doesn't load at the till, see [what to do](#payment-form-didnt-load).

![The Legacy tab at checkout: the payment page from the store with the Checkout Settings button at its top right, and the Process Payment button below it](/img/2.x/support/performance/checkout/en/tablet-light-regular--cp-3-legacy-page.png)12345

1. **Payments** — Cash, Card, card readers and the other tiles in the app. They load no page.
2. **Legacy** — gateways that run on your store's own payment page.
3. **Checkout Settings** — opens the form for choosing which styles and scripts this page loads. The page around it is sent by your website.
4. **Process Payment** — greyed out until the page has loaded.
5. **✕** — back to the cart, with the order kept.

To remove styles and scripts from this page:

1. Sign in to the POS as a shop manager or administrator. A cashier can open the form but can't save it.
2. Press **Checkout**, open the **Legacy** tab, and press **Checkout Settings** on the payment page.
3. Untick a style or script to remove it. Start with your theme's styles, such as `classic-theme-styles` on a classic theme, then scripts your gateway doesn't need, such as `selectWoo`.
4. Press **Submit**, then try a test payment with each Legacy gateway you use.

What the Checkout Settings form shows

![The Checkout Settings form open on the Legacy tab's payment page: Disable wp\_head and Disable wp\_footer at the top, then the styles list and the scripts list side by side, with greyed entries that are always removed](/img/2.x/support/performance/checkout/en/tablet-light-regular--cp-4-checkout-settings.png)12

1. **Legacy** — the tab the form belongs to.
2. **Checkout Settings** — the form, over the payment page. Every style and script on the page has a checkbox, ticked if it loads.

The form has three parts, from the top:

* **Disable All Styles and Scripts** — **Disable wp\_head** and **Disable wp\_footer** remove everything the page's header or footer would load, including what the payment form needs. Use them only to test whether styles and scripts are the cause.
* **Disable Selected Styles**, on the left — one entry per style. Your theme's styles are named after it, such as `twentytwentyfive-style`.
* **Disable Selected Scripts**, on the right — one entry per script.

Greyed entries ending *always removed on the POS payment page* are removed already and can't be ticked.

Keep what your gateway needs

If a payment method stops working after you remove a script, tick it again and press **Submit**.

What WCPOS removes on its own, and options for developers

The payment page always drops the admin bar, the extra links WordPress adds to a page's header, and these WooCommerce styles and scripts:

* Styles: `admin-bar`, `woocommerce-general`, `woocommerce-inline`, `woocommerce-layout`, `woocommerce-smallscreen`, `woocommerce-blocktheme`, `wp-block-library`
* Scripts: `admin-bar`, `wc-add-to-cart`
* With WooCommerce Stripe older than 11.1.1, also its `wc-stripe-upe-classic` script and styles and `stripelink_styles`.

For developers:

* Saving the form needs the `manage_woocommerce` capability.
* The filters `wcpos_payment_template_dequeue_style_handles` and `wcpos_payment_template_dequeue_script_handles` add handles to the removed lists.
* The template can be overridden by copying it to `yourtheme/woocommerce-pos/payment.php`. The original is [templates/payment.php](https://github.com/wcpos/woocommerce-pos/blob/main/templates/payment.php) in the plugin.
* Only styles and scripts added with `wp_enqueue_style` and `wp_enqueue_script` can be removed. A theme or plugin that prints its code straight into the page can't be; ask its developer to enqueue it, or remove it with that plugin's or theme's own hooks (for a theme, in a child theme).

## If something goes wrong[​](#goes-wrong "If something goes wrong으로 직접 링크")

### The store isn't answering[​](#store-not-answering "The store isn't answering으로 직접 링크")

*"The store isn't answering. Keep waiting, or go back to the cart."* Your store is taking more than 4 seconds to save the order. Keep waiting, or press **✕** to go back to the cart with the order kept. If you see it often, [time a test sale](#time-a-sale) and check the causes under [Speed up saving and paying](#saving).

### The store has not answered the last payment[​](#payment-not-answered "The store has not answered the last payment으로 직접 링크")

*"The store has not answered the last payment. Try again to confirm it; it will not be taken twice."* Press **Try again**.

### The payment form didn't load[​](#payment-form-didnt-load "The payment form didn't load으로 직접 링크")

*"The payment form didn't load — check the connection to your store, then retry."* The Legacy tab waited 90 seconds for the payment page, reloaded it, waited another 90 seconds, and gave up. Check the connection and press **Retry**. If the page is slow every time, see [Speed up the Legacy tab's payment page](#legacy-page).

### You don't have permission to modify checkout settings[​](#no-permission "You don't have permission to modify checkout settings으로 직접 링크")

*"You do not have permission to modify checkout settings."* You pressed **Submit** in **Checkout Settings** as a cashier. Sign in as a shop manager or administrator.

### Still slow[​](#still-slow "Still slow으로 직접 링크")

If checkout keeps taking more than 10 seconds after all this, or you suspect a plugin but can't find which one, ask on [Discord](https://wcpos.com/discord). Press **Copy debug info** in **Store health → Logs** and paste it in, with the times from [your test sale](#time-a-sale) and what you've tried. See [Help & Troubleshooting](/ko/troubleshooting/contact-support.md).

With WCPOS Pro

Gateways other than Cash and Card need [WCPOS Pro](/ko/getting-started/pro-license.md).

## Related Documentation[​](#related-documentation "Related Documentation으로 직접 링크")

[Order Storage (HPOS)Check how WooCommerce stores orders, and switch to HPOS](/ko/troubleshooting/performance/order-storage-hpos.md)

[Server PerformanceHosting, caching and database tuning](/ko/troubleshooting/performance/slow-server.md)

[Store HealthMeasured response times, sync presets and the activity log](/ko/troubleshooting/store-health.md)