Building MyZubster: Marketplace Coverage, Payments and Cleaner Subscription Architecture
Today we completed an important step in the evolution of MyZubster: making the Marketplace more complete while cleaning up how paid access is represented across the platform.
The work touched two areas that initially looked separate โ Marketplace categories and payments โ but are actually closely connected when you're building a real ecosystem.
Marketplace: from partial demos to 12/12 category coverage
The main Marketplace already supported 12 categories, but there was an inconsistency.
Users could create listings using all of them, while the integrated demo content covered only six:
seeds, produce, clothing, event_equipment, tools, and services.
We completed the missing coverage by adding demo listings for:
๐ฑ Plants
๐ Accessories
๐ค Volunteering
๐ถ Pet adoption
๐ Lost & found pets
๐พ Pet services
The important part wasn't simply adding six cards.
The demos now live inside the actual Marketplace experience, rather than being isolated examples disconnected from the application.
We also added regression coverage so that if a new Marketplace category is introduced in the future without a corresponding demo, the test suite can flag the missing coverage.
Result: 12 categories, 12/12 demo coverage.
Payments: discovering that โฌ9.90 doesn't always mean the same product
While working on Zorgax monetization, we encountered a useful real-world billing problem.
An account had an active โฌ9.90/month Stripe subscription, while Zorgax displayed:
Zorgax: Free
At first sight that looked like a broken payment migration.
It wasn't.
After tracing the production subscription, we found that the payment belonged to the Marketplace Seller membership, not Zorgax Pro.
Both products happened to use the same price point.
That distinction matters.
A billing system should never grant access to Product B simply because a user paid the same amount for Product A.
Separating Seller from Zorgax
We changed the interface so that these memberships are now represented independently.
The account can correctly show:
Zorgax: Free
Marketplace: Seller active ยท until 04/10/2026
Instead of pretending that one subscription applies to both products.
The Seller CTA also recognizes the existing membership and changes to Seller active.
No Stripe metadata was rewritten.
No fake Zorgax entitlement was created.
No duplicate payment was requested.
The billing record remains attached to the product that was actually purchased.
Under the hood: cleaning up Zorgax monetization
This work also followed a larger monetization refactor.
Zorgax payments are moving toward a unified architecture based on:
PaymentIntent โ Purchase โ Entitlement
BTC checkout keeps dynamic EUR โ BTC quoting and independent settlement verification, while Stripe activation feeds the same entitlement model.
Legacy payment and subscription models have been reduced to compatibility paths instead of remaining parallel sources of truth.
That gives us a much clearer rule:
A payment proves that money moved.
A purchase records what was bought.
An entitlement determines what the user can access.
Those three concepts should not be interchangeable.
Why this matters
These changes aren't visually huge.
There are no dramatic redesigns or flashy new dashboards.
But they remove several classes of problems that become painful later:
duplicate subscriptions, incorrect access grants, ambiguous โฌ9.90 payments, disconnected demo content, and multiple billing systems disagreeing about what a user owns.
The result is a MyZubster Marketplace that is more complete and a monetization layer that better understands the difference between paying money and owning a specific product.
Current status
Marketplace: 12/12 categories represented.
Seller subscription: independently detected and displayed.
Zorgax subscription: independently managed.
Stripe: live subscription state preserved.
BTC: supported through the Zorgax crypto checkout architecture.
Duplicate payment required: no.
Small infrastructure decisions like these are what turn a collection of features into an ecosystem.
Building MyZubster, one layer at a time.
Top comments (0)