Direct answer
Add Buy Now as a second submit button inside WooCommerce's native simple or variable product form. Let WooCommerce validate and add the selected product, preserve every existing cart item, and redirect to the native checkout only after the add succeeds. Keep the normal Add to Cart button.
Buy Now Button for WooCommerce implements this bounded path. Free enables it globally for supported products. Pro adds a plain-language label, audience, and named product or category choices.
“Buy now” describes a destination, not permission to bypass the cart
Merchants usually mean “add this selection, then take the shopper to checkout.” They do not necessarily mean “delete everything the shopper already chose.” A cart-clearing shortcut can surprise a buyer, discard work, and create a support issue that is difficult to reverse.
A current WordPress.org support discussion explicitly asks for both Add to Cart and Buy Now. Another reports a sold-individually product failing when it is already in the cart. A third describes AJAX trouble with grouped products.
These are useful boundary reports. They show what merchants notice and where quick-buy implementations can conflict with product rules. They do not prove one universal root cause or that every competing plugin fails.
Use WooCommerce's native form contract
WooCommerce's simple-product add-to-cart template submits a product identifier through the native form. Its variation template keeps variation attributes and the selected variation in that same form.
A second submit button can reuse those controls. It should submit the native add-to-cart value, leave the quantity and variation inputs in place, and add only a small marker proving that the shopper chose Buy Now.
That design lets WooCommerce remain the authority for:
- product existence and visibility
- purchasable and stock state
- quantity rules
- required variation attributes
- valid variation combinations
- sold-individually rules
- add-to-cart notices
- cart session storage
A helper that reconstructs these rules in JavaScript creates a second source of truth and a larger compatibility surface.
Redirect only after WooCommerce accepts the add
WooCommerce's form handler processes the native request and uses its redirect filter after add-to-cart handling. A Buy Now plugin can inspect its own nonce-protected marker there.
The redirect decision should require all of these facts:
- The custom Buy Now marker is present.
- Its WordPress nonce is valid.
- WooCommerce did not record an add-to-cart error.
- WooCommerce supplies a nonempty checkout URL.
If any fact is missing, return the native redirect unchanged. This matters for invalid variations, unavailable stock, sold-individually conflicts, extension validation, and future WooCommerce behavior.
Never clear or replace the existing cart
Cart preservation is not an optional detail. It is the product contract. The implementation should never call an empty-cart method, create a replacement cart, overwrite session contents, or silently change quantities already present.
A useful acceptance test starts with product A already in the cart. The shopper opens product B, chooses Buy Now, and reaches native checkout. Both A and B must remain. The test should compare product IDs, quantities, totals, and checkout destination before and after.
The same test needs a failure branch. Submit a variable product without required attributes or a sold-individually product that WooCommerce rejects. Checkout must not open, and the prior cart must remain unchanged.
Keep Add to Cart beside Buy Now
Buy Now is a shortcut for a shopper who is ready to check out. Add to Cart is still useful for comparison, bundles, multi-item orders, and continued browsing. Replacing the original button turns a small convenience into a storewide buying-flow decision.
The safer visual hierarchy is two familiar buttons in the native form. The theme can style its normal button classes, and the markup remains accessible without a JavaScript application or custom modal.
On mobile, test the actual rendered form. Both controls must stay inside the viewport, labels must wrap or fit, and neither button should cover quantity or variation controls.
Limit the first release to simple and variable products
Grouped, external, subscription, bundle, composite, booking, and extension-defined products can have different add semantics. “Support everything” is not a credible first-release promise.
Simple and variable products provide a clear native form contract. Unsupported product types should show no extra button and keep their original behavior. This is a fail-passive boundary, not a missing fallback script.
The grouped-product support report above is exactly why the boundary should be explicit. A merchant is better served by a button that does nothing on an unsupported form than one that guesses and changes the cart incorrectly.
Product targeting should use names, not internal IDs
Nontechnical merchants should not copy numeric product or taxonomy IDs into comma-separated text fields. A Pro interface can use WooCommerce's searchable product selector and named category selector, with hard limits such as 50 products and 20 categories.
The targeting rule should remain easy to state: show the button when the product is selected directly or belongs to a selected category, then apply the chosen audience of everyone, guests, or signed-in customers. Leaving both selection lists empty means all supported products.
This is enough for common campaigns without becoming a general condition builder.
Test the behavior that can hurt revenue
A settings page rendering correctly is weak evidence. Release verification should cover:
- Simple product add and checkout redirect.
- Valid variation add and checkout redirect.
- Invalid variation with no redirect.
- Existing cart item preserved.
- Requested item added exactly once.
- Native checkout URL used.
- Add to Cart still present and functional.
- Grouped and external products unchanged.
- Guest and signed-in Pro audiences.
- Selected product, category, and unselected product paths.
- Desktop and narrow mobile layout.
- Deactivation, update, downgrade, rollback, and uninstall invariants.
Tests should run against a real WooCommerce site as well as unit-level policy checks. The release should preserve products, variations, categories, stock, prices, carts, orders, and checkout settings through every lifecycle drill.
Security and resource boundary
The custom action needs a nonce so an arbitrary query parameter cannot request a Buy Now redirect. Administrative changes need manage_woocommerce, settings nonces, sanitized text, bounded ID arrays, and escaped output.
The storefront cost is one extra HTML button on eligible single-product forms and one request-local redirect check after a submitted add. There is no frontend JavaScript or stylesheet, AJAX layer, cron, custom table, telemetry, remote storefront request, or catalog scan.
Pro's WooCommerce product search and category selector assets belong only on the plugin's settings screen. They should never be enqueued sitewide.
Rollback and failure behavior
Deactivating Pro returns the global Free button. Deactivating Free removes the extra button and redirect marker. Existing cart sessions and native checkout remain because the plugin never owns them.
When the Pro license or service is unavailable, Free continues locally. When a product term lookup fails, a fail-passive implementation should preserve the visible Free result instead of hiding a purchase action based on uncertain data.
Default uninstall can preserve bounded settings for accidental recovery. Explicit deletion should remove only the plugin's Free switch, Pro rules, and Pro license state.
Market boundary
Broad direct-checkout products already sell quick-purchase functionality, including Direct Checkout for WooCommerce. That supports willingness to pay around faster checkout, but active installs are not paid customers and competitor pricing is not a StoreFixKit revenue forecast.
The focused product is intentionally smaller: keep both buttons, preserve the cart, use native checkout, and expose only bounded visibility choices. Launch decisions should follow measured activation, trial, conversion, support, refund, and retention cohorts.
FAQ
How do I add a Buy Now button in WooCommerce?
Add a second submit button inside the native simple or variable product form and redirect only after WooCommerce successfully adds the selection.
Does Buy Now empty the cart?
Not with this implementation. Existing items remain, and the selected product is added before native checkout opens.
Does it work with variable products?
Yes. The shopper must choose a valid variation, and WooCommerce performs its normal validation before any redirect.
What happens if the product is already in the cart?
WooCommerce applies its normal quantity and sold-individually rules. If the add fails, the plugin does not force a duplicate or open checkout.
Does it support grouped or external products?
No. The first release deliberately renders nothing for unsupported types rather than guessing their purchase contract.
What happens when Pro expires?
The complete Free global button continues locally. Pro-only label, audience, product, and category choices stop applying.
Focused plugin
Use the one-job implementation.
Add a second Buy Now button to native simple and variable product forms, keep the current cart, and redirect only after WooCommerce successfully adds the selection.