Fast cart Pro

Fast cart puts the basket in a drawer or a centred panel. A customer can change a quantity, remove a line, apply a coupon and see the total without leaving the page they are on.

What opens it

• Automatically, after adding something to the basket.
• A floating button, in the corner you choose.
• Any link to your cart page. Fast cart intercepts the click and opens instead.

Every route still works without JavaScript

This is worth being specific about, because it is the difference between a convenience and a liability.

Cart links stay cart links in the page’s HTML. The floating button is an ordinary link to your cart page. The drawer’s "Go to checkout" and "View full cart" are ordinary links. Nothing is hidden or disabled on the server to make room for the drawer.

So if the script is blocked, fails to load, or hits an error, the customer navigates to your cart page. They may not notice anything happened. And if a request from inside the drawer fails, the drawer stops guessing and sends them to the full cart rather than showing a number it is no longer sure about.

The panel is rendered on your server

Every amount in the drawer — line totals, coupon discounts, the order total — is calculated by WooCommerce and StoreMaster’s pricing pipeline and sent to the browser as finished HTML. The drawer never does arithmetic.

That is why a wholesale price, a running discount campaign, a configured product’s option charges and a quantity rule all behave in the drawer exactly as they do at checkout. There is only one implementation of money, and the drawer is looking at it.

It also means a refused change explains itself. Ask for three of something with a minimum of five and the drawer says so, in the same words the product page uses.

What it will not estimate

Shipping and tax are not shown in the drawer, and the drawer says they are calculated at checkout.

The drawer has no delivery address. Any figure it invented would be wrong for most customers and would then change at checkout — which is the single most common complaint about cart drawers, and an easy one to avoid by not doing it.

Embedded checkout

You can let customers complete their order inside the panel rather than going to the checkout page. What appears there is WooCommerce’s own checkout — its fields, its gateways, its validation — rendered into the panel. Nothing about the checkout is reimplemented, because a second place for a payment to go wrong is not an improvement.

StoreMaster will only do this when it can host every payment method your store currently offers. If it cannot — an off-site gateway, or one it does not recognise — embedded checkout switches itself off, tells you which payment method caused it, and sends customers to your normal checkout page, which works exactly as it always did.

The setting alone never turns it on. The check runs every time, including at the moment a customer clicks: if a new gateway appeared since the page loaded, the click navigates instead of showing a form that cannot take their money.

This is deliberately cautious. A panel that looks like a checkout and cannot take money is worse than a link.

Coupons and cross-sells

Both are optional. Coupons follow WooCommerce’s own rules, so a coupon that would not apply at checkout does not apply here either. Cross-sells come from the cross-sell products you have already configured on your products.

Accessibility

The panel is a dialog: it takes focus when it opens, keeps Tab inside itself while it is open, closes on Escape, and gives focus back to whatever opened it. Changes are announced to screen readers. Every control has a label that names the product it acts on, so "Remove" is never ambiguous in a list of five.