Before
WooCommerce Subscriptions is the most widely used subscription billing plugin globally and handles the recurring payment logic for subscription box businesses, SaaS products, and membership sites built on WooCommerce. The plugin's default failed payment behaviour is to retry the failed charge a small number of times at short intervals and then mark the subscription as suspended or cancelled. This default is insufficient for recovering a significant portion of the failed payments that subscription businesses experience. Payment failures on subscription charges fall into two categories: hard failures (card declined, card expired, card reported stolen) and soft failures (insufficient funds, do-not-honour from the issuer, temporary processing error). Soft failures are recoverable with a correctly timed retry sequence. Industry data across subscription businesses consistently shows that 15-30% of failed subscription charges are soft failures that would have been recovered with a retry sequence and a customer communication workflow. WooCommerce Subscriptions supports custom retry rules. Configuring a dunning management workflow requires setting specific retry intervals (typically day 1, day 3, day 5, day 7 for soft failures), sending customer emails at each failure point prompting card update, and escalating to a final cancellation notice only after the retry sequence is exhausted. WooCommerce Subscriptions does this natively; it is a configuration task, not a development task, but it is a configuration task that most WooCommerce Subscriptions installs have not completed.
After
After WooCommerce Subscriptions dunning is correctly configured, the subscription cancellation rate from payment failures drops. Failed charges that were previously resulting in immediate cancellation after one or two retry attempts are now going through a full retry sequence with customer communication, recovering a portion of the revenue that was previously lost silently.
Before
US B2B WooCommerce stores that manage account-level pricing through manual methods — creating duplicate products with trade prices, applying flat discount percentages via custom user roles, or maintaining pricing spreadsheets and updating prices manually — create two problems that compound as the catalogue grows. The first is maintenance overhead: every time a product price changes, it must be updated in multiple places. Every time a new B2B account is onboarded with custom pricing, someone on the team needs to manually configure the pricing for that account. Every time a new product is added, the B2B price must be set separately from the retail price. The second is pricing errors: manual pricing management at scale produces errors. A product gets a B2B price that was not updated after the retail price changed. A new account is assigned to the wrong pricing tier. A promotional price is applied to the retail price but not reflected in the B2B price. Dedicated B2B pricing plugins for WooCommerce — B2BKing, WholesaleX, and similar — handle account-level pricing, tiered pricing, customer group pricing, and minimum order quantities in a single configuration layer. The retail price and the B2B pricing rules are managed in one place, and new B2B accounts can be assigned to a pricing tier without manual per-product configuration.
After
After B2B pricing is moved to a dedicated plugin, the maintenance overhead of managing account-level pricing drops significantly. New B2B accounts are assigned to a pricing tier on registration. Product price updates are made once and reflected across all pricing tiers. Pricing errors from manual management stop occurring.
Before
WooCommerce stores with large catalogues make database queries that are proportionally heavier than stores with small catalogues. Product listing queries on a catalogue of 3,000+ products — particularly with filtering, variable products, and product attributes — generate significant database load. On shared hosting, where CPU, memory, and database connections are shared across multiple websites on the same server, this load competes with the other sites on the server. The symptoms are consistent: product listing pages taking 4-8 seconds to load, checkout timing out under moderate concurrent traffic, and database errors appearing in the WooCommerce error log. These issues are often misdiagnosed as code problems — theme or plugin conflicts — when the root cause is that the hosting environment is inadequate for the catalogue size and traffic load. Shared hosting is appropriate for WooCommerce stores up to approximately 1,000 products with low to moderate traffic. Above that, a VPS or managed WordPress hosting plan with dedicated CPU and memory allocation is required. For stores in the 3,000-10,000 product range, a managed WordPress host with server-level object caching, a CDN, and a dedicated database server is the appropriate configuration. The WooCommerce product lookup tables, which provide indexed product queries for variable products and product attributes, should also be enabled and verified as populated correctly.
After
After a performance fix — whether that is a hosting upgrade, caching configuration, or both — product listing pages and checkout load at acceptable speeds. The checkout timeout errors stop. The database errors in the WooCommerce error log are resolved. Your store functions at the performance level that your catalogue size and traffic requires.
Before
US WooCommerce stores processing card payments via Stripe are not protected by fraud screening by default in the same way that Shopify stores are. Shopify includes a basic fraud analysis layer on all plans, and Shopify Payments includes Stripe Radar integration. A WooCommerce store using Stripe for WooCommerce has access to Stripe Radar but must configure it explicitly: setting up Radar rules in the Stripe dashboard to block or review transactions based on risk signals, enabling 3D Secure authentication for transactions above a threshold, and configuring CVV and address verification requirements. Without fraud screening, WooCommerce stores processing card payments are exposed to card testing attacks (automated attempts to validate stolen card numbers using small transactions), carding (purchasing low-value items with stolen cards to test viability before larger fraud), and friendly fraud (chargebacks from customers who received their order but dispute the charge). Card testing attacks in particular can generate hundreds of declined transactions in a short period, resulting in Stripe account flags and potential processing suspension. Configuring Stripe Radar rules for a WooCommerce store, enabling velocity checks (blocking multiple transactions from the same IP in a short window), requiring CVV match, and setting address verification requirements reduces fraud exposure significantly. For stores with higher fraud rates, MaxMind's minFraud service integrates with WooCommerce via a plugin and provides a risk score per transaction before the payment is processed.
After
After fraud screening is configured, card testing attacks are blocked by Stripe Radar velocity rules rather than generating hundreds of declined transactions. Your chargeback rate drops as fraudulent orders are flagged for review before they are processed.
