WooCommerce Subscriptions and Memberships Together: The Complete Architecture

To run WooCommerce subscriptions and memberships together, choose separate systems of record for money and access, then define an explicit status-to-access contract between them. Every checkout, renewal, failure, grace period, pause, cancellation, expiration, refund, and plan switch must update or re-evaluate the member's entitlements without blocking payment recovery or creating duplicate access.

The architecture is a state machine connected to an authorization decision. Billing state and access state are related, but they are not the same record or the same business question.

Key takeaways

• Write the billing-to-access contract before configuring either plugin.
• Decide which record owns cancellation, pause, fixed dates, switching, manual grants, and history.
• Keep account, login, Pay Now, update-payment, password reset, checkout, webhooks, and support outside broad gates.
• Test multiple subscriptions, missed webhooks, grace, plan switches, and cache behavior.
• A separate membership record improves independent administration; direct entitlement evaluation removes a sync layer. Neither is always better.

What is the core architecture?

Product or plan → checkout order → subscription/billing state
                                       ↓ policy
Member identity → access conditions → content/product/download/feature

The billing side proves what the customer bought, how it renews, whether payment succeeded, and what lifecycle state exists. The access side decides which current evidence permits a page, product, download, community room, discount, role, or feature.

Do not let a WordPress role become an accidental single source of truth. WordPress defines roles as capability bundles (WordPress roles and capabilities). A role can be a useful compatibility output, but it does not prove that a renewal is paid now.

Which system should own each responsibility?

Assign one authoritative record per responsibility and document every synchronization or evaluation edge. Two systems that both believe they own cancellation or access revocation will eventually conflict.

Official WooCommerce two-record architecture versus ArraySubs

WooCommerce Memberships can work alone for set-length access and can integrate with Woo Subscriptions for recurring membership. The combined official stack normally has a subscription record plus a linked user-membership record. Depending on the membership-length configuration, access can follow subscription state or can be decoupled after payments finish (WooCommerce Memberships and Subscriptions integration).

Current ArraySubs uses an integrated alternative. The subscription, product, purchase, role, and optional feature data remain the records; Members Access evaluates them directly instead of maintaining a second membership custom post type.

The separate-record model supports dedicated membership history and manual administration. The integrated model removes one record synchronization layer. Both still depend on accurate payments, statuses, rules, caches, and support operations.

What status-to-access contract should be defined?

Use this as a fill-in policy, not as fixed ArraySubs or Woo behavior.

WooCommerce's documented lifecycle distinguishes active, on-hold, pending cancellation, cancelled, and expired; pending cancellation keeps special access through the prepaid term in the documented Woo Subscriptions model (WooCommerce subscription status guide). Verify equivalent behavior in the chosen ArraySubs configuration rather than assuming it.

Current ArraySubs active-subscription and variation checks include active and trial. Explicit status conditions can target other states. Role Mapping can keep or remove roles on hold and removes ended-state mappings only when no other active subscription still requires the role.

How should products, plans, variations, roles, and entitlements relate?

Use each layer for the job it represents:

• Product: commercial offer and stable access source.
• Variation: tier or billing-cadence distinction when the difference is meaningful.
• Subscription: lifecycle and renewal relationship.
• Membership plan: independent access record in a separate-ledger architecture.
• Role: compatibility/capability bundle for WordPress components.
• Feature entitlement: specific Boolean, text, or numeric right shared across products.
• Rule: condition plus target, denied action, priority, and schedule.

Do not make “Gold,” “Pro,” or “Member” mean a different thing in every layer. Maintain one naming and ID registry that maps public tier language to products, variations, roles, features, rules, and support documentation.

How should payment failure and grace affect membership access?

A failed renewal is not automatically a final loss. Determine:

• who owns collection: local ArraySubs Stripe, customer/manual, or remote provider;
• how long active and on-hold grace last;
• whether full, reduced, or no paid entitlement remains;
• which physical or service fulfillment stops earlier;
• which account and recovery actions must remain accessible;
• what verified late payment restores;
• what happens when recovery ends: cancellation, manual review, or fallback.

Use the subscription grace-period explainer to design the four clocks. Never gate /my-account/, login, password reset, Pay Now, payment-method updates, checkout, gateway return routes, webhooks, privacy, or support with a broad member-only prefix unless a tested exception preserves them.

What happens during cancellation, expiration, and fixed periods?

Separate immediate cancellation from cancel-at-period-end. Paid-through access normally needs the subscription state/effective date to remain eligible until the documented boundary. An immediate administrative cancellation may remove access sooner and can require a refund or service decision.

Fixed access duration can also differ from the billing schedule. A member might pay in installments for a term, finish paying while access continues, or retain earned downloads/certificates after recurring access ends. The official Woo integration supports membership-length choices with different post-payment effects; ArraySubs Pro Fixed Period Membership supplies its own absolute/annual cutoff model.

Every policy should specify:

• access end source and timezone;
• what is permanent versus term-based;
• pending-cancellation representation;
• refund and chargeback handling;
• rejoin start date and drip behavior;
• data retention and export.

How should upgrades, downgrades, and multiple subscriptions work?

Plan switching has two clocks: financial effect and entitlement effect. Decide whether each changes immediately or at renewal. Test old/new products, variations, roles, features, delayed rules, price/proration, and gateway agreement.

When one customer holds two qualifying subscriptions:

• ending one must not remove a shared role still justified by the other;
• feature aggregation must use the intended sum, max, or any model;
• access should not duplicate downloads, shipments, messages, or membership records;
• the earliest qualifying start used by a drip rule can unlock sooner than a new purchase suggests.

How do rule precedence and conflicts affect the architecture?

Current ArraySubs conflict behavior gives a per-post restriction more specificity than a URL rule. URL rules are evaluated in ascending numeric priority and stop after the first match. Shop rules use stored order and the first applicable product target wins.

Overlaps must be governed. A broad URL redirect and a post-specific message can produce different experiences for what looks like the same content.

Maintain an inventory with rule ID/name, owner, condition, target, priority/order, denied action, schedule, exceptions, creation reason, last test, and rollback. Review it before editing a shared product, feature name, URL branch, or role.

What reconciliation chain proves that billing and access agree?

Every transition should reconcile:

gateway truth
→ order state
→ subscription state and dates
→ access condition or membership state
→ role when used
→ content/product/download/feature visibility
→ customer portal and message
→ future scheduled jobs
→ audit evidence

If the gateway is paid but the order remains pending, do not charge again. If the order is paid and access remains blocked, do not tell the customer to update a valid card. Fix the failed link idempotently and record the correction.

Required launch test matrix

Test at least:

1. checkout succeeds but redirect is interrupted;
2. gateway succeeds but webhook/order update is delayed;
3. trial starts and ends;
4. renewal fails in grace and then recovers;
5. on-hold keep/remove policy;
6. cancel-at-period-end before the paid-through date;
7. immediate administrator cancellation;
8. fixed membership end before/after billing end;
9. pause and resume;
10. immediate and next-renewal switch;
11. two subscriptions grant the same resource/role;
12. refund and chargeback;
13. manual grant and revocation;
14. product or feature key renamed/deleted;
15. cached member page served to guest, and vice versa;
16. payment/account routes under a broad URL rule.

For each case, verify the full reconciliation chain and capture before/after evidence. The complete planning worksheet is in How to Create a WooCommerce Membership Site.

When is a separate membership, LMS, or identity layer needed?

Use another or additional layer when staff need independent membership records, cohorts, credentials, association history, prerequisites, progress, certificates, organization seats, identity federation, remote community authorization, or a native metered newsroom paywall.

Current ArraySubs fits when direct evaluation from WooCommerce and ArraySubs records is sufficient and protected resources live in WordPress/WooCommerce. It does not mirror official Woo membership statuses or provide an independent membership CPT.

Use combined conditions, URL prefix lockdown, and inline content gating for implementation after policy is settled.

Final recommendation

Treat subscriptions and memberships together as a controlled contract between financial state and authorization. Name every system of record, map every lifecycle state, preserve recovery routes, govern rule precedence, and test the complete gateway-to-entitlement chain—including multiple subscriptions and missed events—before launch.

After that architecture is proven, review ArraySubs Pro pricing and the wider member experience feature set.

Frequently asked questions

How do WooCommerce subscriptions and memberships work together?

The subscription supplies billing and lifecycle evidence. A membership record or access-rule engine translates that evidence into content, product, download, role, discount, or feature entitlement.

Which plugin should own access status?

Choose one authoritative membership record or rule engine. Other systems may synchronize or derive roles, but ownership should be explicit and auditable.

Should membership access follow subscription status exactly?

Not always. Trial scope, grace, paid-through cancellation, permanent purchases, earned assets, fixed terms, and manual grants can intentionally differ.

What happens during a failed-payment grace period?

The merchant chooses full, reduced, or suspended paid access while keeping login and payment recovery reachable. Match customer copy to the enforced policy.

What if a customer has two subscriptions?

Evaluate both. Ending one must not remove shared access still granted by the other, and aggregation/fulfillment must avoid duplication.

Does ArraySubs maintain a separate membership record?

No equivalent membership-plan/user-membership CPT exists in the inspected version. Access is evaluated from subscription, product, purchase, role, and optional feature data.

Author, technical review, and verification environment

Author: Emran, ArrayHash — product and editorial work across WooCommerce subscription and membership architecture.

Technical reviewer: ArraySubs Engineering Team — review scope includes billing/access records, statuses, role lifecycle, rules, conflicts, schedules, gateways, and reconciliation.

Verification environment: Source and live UI review of ArraySubs 1.8.11 and ArraySubs Pro 1.1.2 on July 16, 2026, plus current WooCommerce and WordPress documentation. No live status transition or access mutation was performed on the mirror.

Disclosure, limitations, and update log

• Commercial disclosure: ArraySubs is an ArrayHash product. The official two-product WooCommerce architecture and integrated alternative are compared neutrally.
• Limitations: Gateways, caches, themes, page builders, external apps, and status configuration can make billing/access transitions asynchronous or inconsistent. Test the deployed stack.
• July 16, 2026: First publication. Verified system-of-record mapping, two architecture models, current status/access and role semantics, conflict precedence, schedule caveats, and the 16-case test matrix.