Run Your First Lifecycle
This is the "prove it works" walkthrough. By the end, you will have seen the complete lifecycle of a B2B customer relationship — from a WooCommerce product to an automatically created entitlement, through renewal, and into suspension. If you complete this page, you understand how MIDDAG Account works.
What you will need
- MIDDAG Account plugin installed and activated
- WooCommerce installed and configured with at least one payment gateway (Stripe test mode is recommended)
- At least one verified Organization with an Owner collaborator (see Create Your First Organization)
- Familiarity with creating WooCommerce products
Phase 1: Create a WooCommerce product
Create a product in WooCommerce that represents something you sell to business customers.
- Go to WooCommerce > Products > Add New
- Give it a name (e.g., "Pro Plugin — Annual License")
- Set a price (e.g., $99.00)
- If testing subscriptions, use the WooCommerce Subscriptions extension and set the billing period to 1 year
- Publish the product
This is a standard WooCommerce product. Nothing special yet.
Phase 2: Map the product to an Entitlement Class
This is where MIDDAG Account connects to WooCommerce. You need to tell the system: "When someone buys this product, what kind of entitlement should be created?"
- Edit your WooCommerce product
- Look for the MIDDAG Account tab in the product data panel
- Set the Entitlement Class to match what this product grants:
- A software plugin? Select Plugin (PLG)
- A managed hosting environment? Select Environment (ENV)
- A consulting service? Select Service (SVC)
- Something else? Select Order (ORD) as a catch-all
- Update the product
TIP
You can also configure Policy overrides at the product level — for example, setting a specific grace period or renewal window for this product. For this walkthrough, the default policies are fine.
Phase 3: Place a test order
Now simulate a customer purchase. You have two options:
Option A: Place the order from the WordPress admin
- Go to WooCommerce > Orders > Add New
- Select the Organization's billing address (or add it manually)
- Click Add item(s) and add your product
- Set the payment method and mark the order as Processing or Completed
Option B: Place the order from the storefront
- Log in as the Organization Owner (or use a test customer account)
- Add the product to the cart
- Complete checkout using your test payment gateway (e.g., Stripe test card
4242 4242 4242 4242) - Confirm the order completes successfully
Either way, you need a paid, completed order linked to your test Organization.
Phase 4: Verify the entitlement was created
This is the moment of truth. When payment is confirmed, MIDDAG Account should automatically:
- Detect the order's line items
- Look up the Entitlement Class mapped to each product
- Create an Entitlement with the correct class, code, and dates
- Link the entitlement to the Organization and the Order
Check it:
- Navigate to MIDDAG Account > Entitlements
- You should see a new entitlement with:
- A code like PLG-2026050001 (matching the class you selected)
- Status: Active
- Organization: your test Organization
- Start date: today
- Expiration date: based on the product's subscription period (or blank for one-time purchases)
- Click on the entitlement to see the full detail view. The linked Order should appear in the related records.
If the entitlement does not appear, check:
- Is the order status Completed (or Processing with payment confirmed)?
- Did you map the product to an Entitlement Class in Phase 2?
- Is the Organization verified?
Phase 5: Check downstream resources
Depending on the Entitlement Class, the system may have automatically provisioned additional resources:
| Entitlement Class | What to check |
|---|---|
| Plugin (PLG) | A License record should exist, linked to this entitlement. Check MIDDAG Account > Licenses. |
| Environment (ENV) | An Environment record should be created or queued for provisioning. Check MIDDAG Account > Environments. |
| Service (SVC) | A Contract record may be created. Check MIDDAG Account > Contracts. |
| Order (ORD) | No automatic downstream resources — ORD is a generic catch-all. |
This automatic provisioning is what makes MIDDAG Account more than a tracking system. The entitlement does not just record that the customer bought something — it triggers the creation of whatever that purchase grants access to.
Phase 6: Simulate renewal
Now test what happens when the entitlement approaches expiration and the customer renews.
- Go to the entitlement detail screen
- Note the Expiration Date (if you set up an annual subscription, it should be one year from today)
- For testing purposes, you can edit the expiration date to a date in the near past — this simulates an expiring entitlement
- When an entitlement expires, its status changes from Active to Expired
To simulate renewal:
- Place another order for the same product, for the same Organization
- When payment is confirmed, the system should:
- Detect the existing entitlement for this product and Organization
- Extend the expiration date (rather than creating a duplicate)
- Return the status to Active
- Verify the entitlement shows the new expiration date and Active status
INFO
The renewal behavior is controlled by the Renewal Policy. Default settings handle most cases, but you can customize the grace period, auto-renewal behavior, and renewal pricing at multiple levels: globally, per entitlement class, per product, per organization, or per individual entitlement.
Phase 7: Simulate suspension
Finally, test what happens when a payment fails or an admin needs to pause access.
Manual suspension (admin action)
- Go to the entitlement detail screen
- Change the status from Active to Suspended
- Add a reason (e.g., "Testing suspension flow")
- Save
What should happen:
- The entitlement status changes to Suspended
- Any downstream resources reflect the suspension (e.g., a linked License becomes inactive)
- If the customer logs into the portal, they see the entitlement as suspended
Reactivation
- Change the status back to Active
- Save
The entitlement and its downstream resources should return to normal operation.
What suspension looks like in production
In a real scenario, suspension is typically triggered by a failed payment:
- Stripe reports a payment failure via webhook
- MIDDAG Account receives the webhook and identifies the affected entitlement
- The Payment Recovery Policy determines how long to wait before suspending
- If the grace period passes without successful payment, the entitlement is suspended automatically
- If payment is recovered (customer updates their card, retry succeeds), the entitlement reactivates automatically
- If the suspension period expires without recovery, the entitlement moves to Cancelled
You do not need to test the webhook flow right now. The manual suspension above confirms that the state transitions and downstream effects work correctly.
What you have proven
If you completed all seven phases, you have verified:
- WooCommerce products can be mapped to Entitlement Classes
- Orders automatically create Entitlements with the correct class and code
- Downstream resources (licenses, contracts, environments) are provisioned automatically
- The entitlement lifecycle (active, expired, suspended, cancelled) works as expected
- Renewal extends existing entitlements rather than creating duplicates
- Suspension pauses access across the entitlement and its connected resources
This is the core operating model of MIDDAG Account. Everything else — quotes, invoices, tax documents, service requests, integrations — builds on top of this foundation.
What to do next
- Core Concepts: Entitlements — deeper explanation of entitlement behavior, parent-child hierarchies, and advanced scenarios
- Core Concepts: Policies — understand the Policy Engine that controls grace periods, renewal windows, and provisioning behavior
- Commerce: Products and Entitlement Classes — detailed guide to mapping WooCommerce products to entitlement classes with policy overrides