From Open Source Marketplace to Real Payments: Integrating Stripe into MyZubster

# stripe# payment# real# integrating
From Open Source Marketplace to Real Payments: Integrating Stripe into MyZubsterDaniel Ioni

From Open Source Marketplace to Real Payments: Integrating Stripe into MyZubster Building...

From Open Source Marketplace to Real Payments: Integrating Stripe into MyZubster

Building features is one thing.

Building a system that can actually generate its first verified revenue is another.

Today, MyZubster reached an important milestone: we completed the integration of a real Stripe-powered subscription flow for MyZubster Seller.

The Seller Membership is priced at:

€9.90/month

This may look like a small technical step — adding a payment provider — but for an open-source ecosystem, it changes something fundamental.

We are moving from:

“The platform can theoretically monetize.”

to:

“The platform has the infrastructure required to accept and verify recurring payments.”

What is MyZubster?

MyZubster is an open-source ecosystem that I’m building around marketplaces, digital services, communities and, progressively, immersive experiences.

The project is developed publicly on GitHub.

One of the main goals is to avoid building monetization as an afterthought.

Instead, the business model, backend architecture, security controls and product experience should evolve together.

That led to the next important milestone:

Connect Seller Membership to a real payment infrastructure.

The Seller Membership

The current commercial model includes a Seller subscription:

MyZubster Seller — €9.90/month

The important part isn't just displaying a pricing card.

A production marketplace needs to know whether a user has actually paid.

That means Seller privileges cannot simply be activated by the frontend.

The backend needs an authoritative source of truth.

For MyZubster, that source is now Stripe.

The architecture

The implementation introduces two main endpoints.

Creating the Checkout Session 

POST /api/marketplace/seller/checkout
Enter fullscreen mode Exit fullscreen mode

This endpoint requires an authenticated MyZubster user.

The backend creates the Stripe Checkout Session using the configured recurring Seller price.

The browser therefore doesn't decide whether the user becomes a Seller.

It only starts the payment process.

Receiving Stripe events 

POST /api/marketplace/seller/webhook
Enter fullscreen mode Exit fullscreen mode

Stripe sends subscription and payment lifecycle events to this endpoint.

MyZubster currently handles events including:

checkout.session.completed
customer.subscription.created
customer.subscription.updated
customer.subscription.deleted
invoice.paid
invoice.payment_failed
Enter fullscreen mode Exit fullscreen mode

These events allow the backend to synchronize the Seller membership with the actual Stripe subscription.

Never trust the browser with revenue state

This was one of the most important design decisions.

A request coming from the frontend should never be able to say:

paymentSuccessful = true
Enter fullscreen mode Exit fullscreen mode

and unlock Seller functionality.

Instead:

User
  ↓
MyZubster
  ↓
Stripe Checkout
  ↓
Payment
  ↓
Stripe Webhook
  ↓
Signature Verification
  ↓
MyZubster Backend
  ↓
Seller Membership State
Enter fullscreen mode Exit fullscreen mode

The server determines the entitlement based on verified Stripe information.

Webhook security

Accepting a webhook endpoint without validating its origin would create an obvious attack surface.

MyZubster therefore verifies Stripe webhook signatures before processing the event.

The implementation uses the raw HTTP request body together with the webhook signing secret.

It also applies a five-minute timestamp tolerance to reduce replay risk.

Conceptually:

Incoming webhook
      ↓
Read raw payload
      ↓
Verify Stripe signature
      ↓
Validate timestamp
      ↓
Parse event
      ↓
Update subscription state
Enter fullscreen mode Exit fullscreen mode

An invalid signature doesn't change membership state.

Subscription lifecycle

A subscription isn't simply:

ACTIVE
Enter fullscreen mode Exit fullscreen mode

or:

INACTIVE
Enter fullscreen mode Exit fullscreen mode

Payments fail.

Subscriptions expire.

Customers cancel.

Renewals happen.

So MyZubster maps Stripe subscription lifecycle information into the Seller entitlement.

For example, when a payment fails, Seller access can be suspended rather than allowing the application to assume the subscription remains valid forever.

Cancellation is also handled through Stripe's subscription lifecycle, including cancellation at the end of the paid period.

Auditability

The Seller Membership model can retain Stripe identifiers associated with the subscription lifecycle, such as the customer, subscription, Checkout Session, price and last processed event information.

This matters because payment systems need to be diagnosable.

When something goes wrong, we need to answer questions such as:

  • Which Stripe customer corresponds to this MyZubster account?
  • Which subscription granted the entitlement?
  • Which Checkout Session started it?
  • Which Stripe price was used?
  • What was the latest relevant payment event?

Revenue infrastructure without traceability becomes painful very quickly.

Fail closed

Another principle we adopted is simple:

Missing payment configuration should disable automated checkout, not accidentally grant access.

The production environment therefore requires the Stripe configuration needed by the payment flow, including the secret API credential, Seller Price ID and webhook signing secret.

Secrets stay outside the repository.

Keeping a manual fallback

Interestingly, introducing Stripe didn't require removing the existing manual Seller verification mechanism.

Instead, the system distinguishes between manually managed and Stripe-managed memberships.

That gives MyZubster a useful fallback while the automated revenue path matures.

It also makes incremental migration possible.

Security gates before merge

Before merging the Stripe implementation, the branch went through the project's automated gates.

The final checks included:

CI – Test e Lint             ✅
Security Audit               ✅
Continuous Evidence Gate     ✅
Enter fullscreen mode Exit fullscreen mode

Locally, the test suite also completed successfully:

Test Suites: 118 passed, 118 total
Tests:       476 passed, 476 total
Snapshots:   0 total
Enter fullscreen mode Exit fullscreen mode

During this process, the security audit detected moderate dependency vulnerabilities.

Rather than ignoring the failing gate just to ship the feature, the dependencies were updated and the audit was run again.

Only after the security workflow returned green was the Stripe pull request merged.

The PR is merged

The implementation was developed through:

PR #900 — feat(marketplace): automate Seller payments with Stripe

It is now merged into the main MyZubster codebase.

For me, this milestone is more important than the number of lines of code involved.

It connects three things that projects often keep separate:

PRODUCT
   +
ENGINEERING
   +
ECONOMICS
Enter fullscreen mode Exit fullscreen mode

The €9.90/month Seller Membership is no longer just an idea documented in a business model.

There is now real backend infrastructure behind it.

What comes next?

The next objective isn't adding another hundred features.

It's validating the complete production loop:

Visitor
   ↓
Account
   ↓
Seller Checkout
   ↓
Stripe Payment
   ↓
Verified Webhook
   ↓
Seller Activation
   ↓
Recurring Subscription
   ↓
Verified Revenue
Enter fullscreen mode Exit fullscreen mode

After that, the interesting metrics start becoming real:

  • checkout conversion
  • paid Seller activation
  • MRR
  • ARR
  • churn
  • payment failure rate
  • retention
  • CAC
  • LTV

Until payments exist, many of those numbers are theoretical.

Once the first real customer pays, they become business data.

Building in public

MyZubster is still evolving.

There are many things left to improve, and that's exactly why I'm building it publicly.

The goal isn't to pretend that an early-stage platform is already a finished company.

The goal is to progressively turn architecture, code, economics and real user behavior into one coherent system.

This Stripe integration represents another step in that direction.

From code.

To product.

To payment.

And eventually, to a sustainable open-source ecosystem.

opensource #stripe #nodejs #webdev