Building MyZubster: When Marketplace Categories Meet Real Payments
Today I pushed another important update to MyZubster, focused on two areas: completing the Marketplace experience and making subscription ownership much clearer.
Marketplace: 12/12 categories covered
The Marketplace already supported 12 categories for real listings, but our integrated demo content only represented six of them.
We added the missing six:
🌱 Plants
🎒 Accessories
🤝 Volunteering
🐶 Pet Adoption
🔎 Pet Lost & Found
🐾 Pet Services
Now every category available to users has at least one corresponding demo inside the actual Marketplace.
I also added a regression test that checks category coverage automatically. If we introduce another Marketplace category later and forget to provide demo coverage, the test will catch it.
That takes us from 6/12 to 12/12 Marketplace demo coverage.
Then came an interesting payment problem
While testing the monetization flow, I found an account with an active €9.90/month Stripe subscription, while Zorgax — MyZubster's AI assistant — was displaying:
Zorgax: Free
At first, this looked like a failed subscription migration.
After tracing the real production payment, however, the system was actually right.
The €9.90 subscription belonged to Marketplace Seller, not Zorgax Pro.
Same price.
Same account.
Different product.
And that's an important distinction in a billing architecture.
A payment isn't an entitlement
We deliberately did not convert the Seller payment into Zorgax Pro just because both products cost €9.90.
Instead, we changed the UI and architecture to represent them independently.
The account can now display:
Zorgax: Free
Marketplace: Seller active · until the actual subscription expiration date
The interface also recognizes the active Seller membership instead of continuing to ask the user to become a Seller.
No duplicate payment.
No fake entitlement.
No rewriting Stripe metadata to make the data fit the UI.
Cleaning up the architecture
The Zorgax monetization work is also moving toward a clearer model:
PaymentIntent → Purchase → Entitlement
Each layer answers a different question:
PaymentIntent: Is there a payment being processed?
Purchase: What did the user actually buy?
Entitlement: What is the user allowed to access?
This separation becomes especially important once one platform contains multiple paid products.
A €9.90 payment by itself should never be enough to decide what somebody owns.
The product identity matters.
Crypto + Stripe
Zorgax also supports a BTC payment path alongside Stripe.
The crypto checkout uses dynamic EUR → BTC quoting and only activates access after payment verification.
Stripe and crypto can therefore be different payment rails while ultimately feeding the same concept of product ownership.
That's the direction I want for MyZubster: multiple payment methods, one consistent entitlement model.
What changed today
Marketplace demo coverage: 12/12 ✅
Marketplace Seller subscription detection: working ✅
Seller and Zorgax subscriptions: separated ✅
Existing Stripe subscription: preserved ✅
Duplicate payment requirement: none ✅
Zorgax BTC checkout architecture: integrated ✅
Regression coverage for Marketplace categories: added ✅
This was one of those development sessions where a seemingly simple UI inconsistency exposed a much more important architectural question:
What exactly did the user pay for?
Getting that answer right matters more than making a green "Pro" badge appear on the screen.
That's how we're continuing to build MyZubster: not just adding features, but making sure the pieces behave like one coherent ecosystem.
MyZubster #WebDevelopment #Stripe #Marketplace #JavaScript #NodeJS #Payments #SaaS #IndieDev #BuildInPublic
