Why per-SKU MOQ counts fail for multi-kit keycap group buys

A group buy can have enough total interest and still fail to produce a valid order set.

The usual dashboard shows demand per SKU: 150 blue base kits, 150 green base kits, 30 NorDe kits. If each base needs 180 orders, both colors appear to miss MOQ. Yet that view loses the most important fact: which complete alternatives each buyer actually approved.

A buyer may approve either:

1. Blue base + NorDe, up to a fixed total price
2. Green base + NorDe, up to the same total price

Those are not four independent checkboxes. They are two complete baskets. Counting SKUs separately can create three bad outcomes:

• counting the same buyer toward two incompatible bases;
• dropping a required language kit to make a base reach MOQ;
• charging for a basket the buyer never approved.

Model consent as sets of complete baskets

For buyer i, store a set of permitted baskets B_i. The allocation chooses at most one basket from each set.

For every manufacturing SKU s, the selected quantity must satisfy its minimum or remain zero. Required components travel with the basket. Price ceilings apply to the final basket, including the store's current shipping and tax calculation.

That gives three practical invariants:

• One buyer, at most one order. Alternatives are mutually exclusive.
• A required part is atomic. If NorDe is required for a selected basket, the base cannot survive without it.
• No silent fallback. An unselected buyer receives no order instead of a partly altered one.

A synthetic example makes the difference visible. Suppose 150 buyers prefer blue, 150 prefer green, and 60 of the green-preferring buyers also approved blue. If 30 buyers require NorDe, a feasible allocation can form 210 complete blue orders and 30 required NorDe kits. Green-only buyers remain unassigned. Nobody is counted twice.

Formation is only half the problem

The allocator can be correct and the operation can still fail after checkout.

A production-safe flow needs to freeze the exact quote before payment, bind every payment attempt to that order, and preserve uncertainty when a provider response is lost. A browser returning to a success page is not payment proof. The store needs provider readback and an idempotent recovery path.

The same complete-basket rule must survive recovery:

• if payment for a required component fails, cancel the whole basket;
• if one required SKU falls below MOQ after recovery, remove every dependent order;
• produce the manufacturing list only after the payment set and final quantities agree;
• never repair a failed group by silently removing parts.

Operational checks matter

Large group buys also need more than a fast local allocation test. Before opening a campaign, verify the actual WooCommerce host, database, scheduler, payment mode, and recovery path at the advertised cohort size. A five-minute server cron and a provider-backed Test run are operational prerequisites, not implementation details.

A narrow WooCommerce implementation

BatchPact implements these constraints for WooCommerce keycap group buys. Buyers approve complete baskets; the store selects one feasible basket per buyer, opens exact WooCommerce orders, and keeps required kits atomic through payment recovery and manufacturing export.

The Free plan supports one campaign with up to 300 reservations and 4 manufacturing SKUs. Starter and Pro raise the campaign limits without weakening the same basket and recovery rules.

It is intentionally narrow. It requires an existing HTTPS WooCommerce store, the official WooCommerce Stripe extension, PHP 8.3+, WordPress 6.9+, MySQL 8.0+ or MariaDB 10.6+, and a real five-minute server cron. Merchants still own catalog, tax, shipping, manufacturing, fulfillment, refunds, and customer support.

If you run group buys with optional bases, required regional kits, or buyer-approved substitutions, the useful question is not “how many people clicked each SKU?” It is “which complete set of orders can we form without violating anyone's permission?”