ROWERR CASE STUDY / SWOOPMATE
WooCommerce Membership Website Development: Live Price Drops & Personalized Product Reordering
WooCommerce membership website development for SwoopMate brought public product discovery, member-only purchases, recurring membership workflows, configurable live price drops and personalised product reordering into one marketplace. Rowerr built the store and two custom engines around the client's shopping model, rather than treating this as a standard membership website.
In this case study
Client requirements
SwoopMate approached Rowerr to build a WooCommerce marketplace from the ground up. The brief combined complete store setup with a member-only buying journey, changing prices and individually ranked product listings.
- Import and organise the product catalogue.
- Integrate Stripe, PayPal and regional payment methods for the intended markets.
- Keep products publicly browsable while restricting purchases to members.
- Provide recurring memberships with gateway-appropriate renewal workflows.
- Configure starting prices, minimum prices, drop amounts and intervals.
- Reorder each member's catalogue using browsing history and interest signals.
Four engineering challenges
| Challenge | Rowerr's approach |
|---|---|
| Public discovery, private purchasing | Separate product visibility from membership eligibility. |
| International and regional payments | Keep WooCommerce checkout and define renewal support per gateway. |
| Continuously falling product prices | Build a custom engine around administrator-defined pricing rules. |
| Relevant discovery for returning members | Build behavioural ranking instead of a fixed catalogue order. |
1. Restrict purchases, not product discovery
The client wanted visitors to see every product and its details before joining. Restricting the entire product page would interrupt that journey.
The MemberPress configuration evaluated for this project restricted product-page access and did not match the combined workflow. This was a configuration and architectural-fit decision, not a claim that MemberPress cannot support WooCommerce integrations.
Rowerr implemented AccessKit as the membership layer. Non-members retain access to product details but see a membership notice and registration path instead of an available purchase button.
The distinction is simple: product visible, details visible, purchase restricted. Keeping pages public supports discovery; it does not guarantee rankings. Purchase eligibility must also be enforced at add-to-cart and checkout, not only in the interface.
2. Connect membership payments to WooCommerce
The payment brief covered international and local gateways. The team considered a stack involving MemberPress, a WooCommerce integration and WooCommerce Subscriptions, then selected AccessKit for the project's WooCommerce-centred membership workflow.
WooCommerce handles checkout and orders; AccessKit provides the membership and access layer. The aim was to reduce additional integrations while keeping membership purchases within the store's existing commerce workflow.
Initial payment support is not the same as automatic renewal support. Recurring charges require a compatible gateway integration and suitable payment authorisation. Each regional method needs its own verified renewal path; the case study does not claim unattended renewals through every WooCommerce gateway.
WooCommerce's gateway documentation explains the distinction between manual and automatic subscription payments.
3. Build a configurable live price-drop engine
SwoopMate's business model needed prices to fall according to rules controlled by the store administrator. Rowerr developed a custom WooCommerce extension rather than forcing this workflow into an unsuitable pricing plugin.
Example pricing rule
Starting price: £500
Minimum price: £300
Price drop: £1 every 30 seconds
This illustrates the configurable rule, not a quoted current SwoopMate offer.
The engine applies the configured pricing cycle and exposes the current price to members. Once the product is purchased, its pricing cycle stops and inventory is updated.
The browser displays the price; the server must approve the payable amount. Checkout rules must address stale prices and competing purchases. Those safeguards are acceptance criteria, not independently audited performance claims.
4. Reorder products around member interest
A fixed or random catalogue was not enough. Returning members needed to find products they had already shown interest in without repeating the same search.
Rowerr developed a behavioural ranking engine using product views, repeat visits, browsing history, returning sessions and interest patterns. The catalogue is reorganised for each member so stronger interest signals move relevant products towards the top.
Live pricing continues alongside that ranking. Personalised product order does not, by itself, mean personalised prices. This case study describes member-specific discovery, not an independently verified per-member pricing algorithm.
The benefit is a more relevant shopping journey. No conversion uplift or revenue increase is claimed without measured results.
Technologies and responsibilities
- WooCommerce: catalogue, inventory, checkout, orders and payment integration.
- AccessKit: membership entitlement, purchase restrictions and the selected renewal workflow.
- Stripe and PayPal: international payment processing.
- Regional gateways: local checkout methods, with renewal compatibility assessed separately.
- Custom live-price engine: configurable price-drop rules and product lifecycle behaviour.
- Custom behaviour engine: member-interest history and personalised catalogue ranking.
Result: a marketplace built around the business model
The delivered solution combines publicly visible products, member-only purchasing, multiple checkout methods, recurring membership workflows, live price-drop automation and behavioural product ranking.
Instead of changing the client's business model to suit an off-the-shelf stack, Rowerr built custom extensions around the required experience while retaining WooCommerce's commerce foundation.
The outcome is functional delivery, not a claimed sales or speed improvement. Project details here come from Rowerr's development account; the FAQs below explain practical implementation considerations rather than certify the production internals.
Visit SwoopMate or explore Rowerr's WooCommerce development services.
Frequently asked questions
Can products stay public while only members buy?
Yes. Treat viewing and purchasing as separate permissions. Keep product details available, then enforce membership eligibility on the server at add-to-cart and checkout. A hidden button alone is not protection.
Why was another membership approach chosen?
The MemberPress configuration evaluated did not fit this project's combined access, checkout and renewal workflow without further integration. AccessKit was selected for that fit, not because MemberPress is incapable of WooCommerce membership use cases.
What does AccessKit do here?
It is the membership and access layer: plans, entitlement rules and purchase restrictions. WooCommerce remains responsible for products, checkout and orders. Keep those responsibilities clear to avoid conflicting membership state.
What alternatives can support this setup?
WooCommerce Memberships with Subscriptions is one alternative; MemberPress can also fit with suitable integration. Compare purchase restrictions, recurring gateways, failed-payment handling and maintenance requirements before choosing a stack.
Can every local gateway renew automatically?
No such assumption is safe. Initial checkout compatibility does not guarantee tokenised or off-session renewal support. Verify the integration and a successful scheduled renewal for each gateway before promising automatic billing.
Can members choose different payment gateways?
Yes, where checkout and membership integrations support them. Classify methods as initial-payment, manual-renewal or automatic-renewal capable. The number of enabled gateways does not establish recurring-payment compatibility.
What happens when a renewal fails?
Record the failure, follow the configured retry policy and notify the member where appropriate. Access should follow confirmed payment status and the membership policy. Test recovery, cancellation and duplicate-event handling.
What should trigger a price drop?
The server should determine the price from the starting amount, floor, elapsed time, interval and drop amount. Background jobs can handle lifecycle events. Browser timers should display changes, not decide the authoritative price.
Are falling prices personalised for each member?
Not necessarily. Product ranking and product pricing are separate systems. SwoopMate's described personalisation concerns catalogue order; member-specific prices would require separate rules, validation and clear customer communication.
How can prices update without a refresh?
JavaScript can fetch the current server price through AJAX and update the price display. WebSockets are another option when justified by scale and latency. Neither approach replaces server-side checkout validation.
Which price applies during checkout?
Define whether checkout uses the latest valid price or a time-limited quote. Revalidate the amount on the server and communicate the rule clearly. A displayed catalogue price should not be blindly trusted.
How do you protect the last item from double sales?
Stock and purchase eligibility need concurrency-safe reservation or locking, followed by final validation. Test simultaneous requests against one-unit stock. Disabling buttons in two browsers cannot prevent a race condition.
Which behaviour signals can rank products?
Views, repeated visits, browsing history and returning sessions can indicate interest. Cart and purchase events can be additional signals if collected. Weighting is custom business logic, not proof of purchase intent or guaranteed conversion.
Should returning members be identified by IP?
Use the authenticated account as the primary identifier. IP addresses can change or be shared. Collect only necessary history and define its purpose, retention and access controls.
How can ranking avoid repeating the same products?
Combine interest with recency and diversity so older behaviour loses influence and relevant alternatives remain visible. This is an implementation option to evaluate, not a claim about SwoopMate's exact production formula.
How should personalised pages be cached?
Do not serve one member's catalogue or private data from a shared cache to another. Cache public content separately and use authenticated dynamic requests or properly isolated cache variants for member-specific information.
Can frequent price drops overload the store?
Yes, if every interval rewrites thousands of product rows. Where appropriate, calculate effective prices from stored rules and reserve background jobs for meaningful events. Load-test checkout, database activity and queue backlog.
How should pricing and payment requests be secured?
Validate identity, permissions, membership, stock and price on the server. Nonces help prevent request forgery but are not authorisation. Verify payment webhook signatures and safely handle repeated events before updating payment state.
Will member-only buying harm SEO?
Not inherently when useful product pages remain public. Explain membership requirements and ensure public price and availability markup match the visible offer. Public access or structured data alone does not guarantee search visibility.
What needs testing after store updates?
Test non-member restrictions, membership purchases, renewals and failures, live pricing, checkout, caching and ranking in staging. Include cancellation and simultaneous limited-stock purchases. Keep actionable logs for payment and background-job failures.