MyZubster Dev Update — Sepolia E2E Payments, Infrastructure Debugging & Interactive Visual Layer

Today we completed another important integration phase for the MyZubster ecosystem.

What initially looked like a simple frontend problem — Marketplace data not loading correctly and interactive visuals returning unexpected pages — turned into a useful end-to-end debugging session across the API layer, Cloudflare Tunnel, PM2, Vercel, the Sepolia environment, static asset delivery, and the Marketplace payment flow.

The result is a cleaner architecture and a new independent visual delivery layer for MyZubster.

1. Sepolia Marketplace API routing fixed

The first issue appeared when the frontend requested:

/api/marketplace/orders/mine

The request returned HTTP 200, but the response was:

Content-Type: text/html

instead of JSON.

The API call was effectively falling through to the frontend application.

We traced the problem to the Cloudflare Tunnel ingress configuration.

The Sepolia hostname was routing everything to the frontend running on port 3010, while the Sepolia API was running separately on:

127.0.0.1:5010

We introduced path-specific routing:

sepolia.myzubster.com/api/* → 127.0.0.1:5010

while keeping:

sepolia.myzubster.com → 127.0.0.1:3010

After restarting the actual cloudflared process — which we discovered was managed by PM2 rather than a standalone systemd cloudflared.service — the public API started returning the expected authenticated JSON responses.

A request without authentication correctly returned:

HTTP 401 application/json

and an authenticated browser request returned the user's Marketplace order.

That confirmed that the public API routing was finally reaching the correct backend.

2. Marketplace order successfully recovered

The Marketplace API returned the real order used during the Sepolia E2E test.

The order contained:

• listing snapshot
• buyer/seller relationship
• quantity
• ETH price
• order status
• payment state
• viewer role

The order was already in:

ACCEPTED

with payment status:

AWAITING_PAYMENT

This gave us the correct starting point for the blockchain payment phase.

3. Incorrect payment endpoint identified

The frontend initially attempted to access:

/api/marketplace/orders/:orderId/payment-intent

That route did not exist.

Express correctly returned:

404 Cannot GET .../payment-intent

Because the response was HTML, frontend code attempting JSON.parse() produced the misleading runtime error:

JSON.parse: unexpected character at line 1 column 1

This was not fundamentally a JSON parser bug.

It was an API contract mismatch.

We identified the actual ETH endpoint:

/api/marketplace/orders/:orderId/payment/eth-intent

Using the authenticated request, this endpoint returned HTTP 200 application/json.

4. ETH payment intent verified

The payment intent returned all the information required to construct and validate the Sepolia transaction:

• asset: ETH
• network: Sepolia
• chainId: 11155111
• chain hex: 0xaa36a7
• expected sender
• expected recipient
• expected amount in wei
• expected amount in ETH
• minimum confirmations
• current payment status
• testnet flag

For this E2E test the expected payment was:

0.0001 ETH

or:

100000000000000 wei

with:

3 confirmations

required by the application flow.

This is important because the payment UI is not simply asking MetaMask to transfer an arbitrary amount. The backend creates a payment intent containing the parameters against which the payment can be checked.

5. Sepolia faucet and wallet funding

The first MetaMask attempt correctly failed with:

Insufficient funds

because the buyer wallet did not contain enough Sepolia ETH to cover both the test payment and network gas.

We funded the wallet using a Sepolia faucet and repeated the transaction.

This allowed the E2E flow to continue through MetaMask on the Sepolia network.

6. Real Sepolia transaction executed

The payment transaction was then submitted successfully.

Transaction hash:

0x14ce86dddc9a86b752d03125308844709456e4b8185cf9a89d9e1e8a25e67eed

This gave us an externally inspectable blockchain artifact for the test.

The transaction was no longer only an application-side state transition: the payment phase had an actual Sepolia transaction associated with it.

7. Visual documentation added to the ecosystem

After completing the E2E work, we collected a new group of MyZubster visual assets covering several areas of the project:

• Kefir donor workflow
• Kefir donors in Rimini and Riccione
• MyZubster ecosystem/community
• Nicola software/cyberpunk narrative
• Sepolia ETH E2E payment flow
• Kefir → Zorgax → GitHub → Tor → Metaverse ecosystem story
• University / Living Lab / LIFE concept

The seven assets were imported onto the VPS and integrated into the project documentation structure.

A dedicated visual archive was also created in the MyZubster repository documentation.

8. GitHub 404 exposed a second infrastructure problem

While making the README documentation interactive, another issue appeared.

Some GitHub destinations currently lead to the existing GitHub-side 404 situation for which a support ticket is still open.

Instead of making the public visual documentation depend entirely on GitHub raw URLs, we decided to create an independent delivery path.

This led to another infrastructure investigation.

9. We discovered the real production routing topology

Initially we placed the assets in the core project's public/ directory.

The files existed correctly, but public requests returned HTML instead of images.

We inspected the running processes and found several distinct services:

• production gateway
• production frontend
• Sepolia backend
• Sepolia frontend
• BTC verifier
• social service
• Cloudflare Tunnel

The production web process was identified as:

/root/repos/MyZubsterWeb/server-static.js

running on port:

5173

and serving:

/root/repos/MyZubsterWeb/dist

After copying the visual assets into the actual static document root, direct requests to port 5173 returned the correct files.

For example:

HTTP 200
Content-Type: image/png
Content-Length: 2162743

This confirmed that the static server itself was working correctly.

10. Vercel vs Cloudflare routing identified

However, requesting the same asset through:

www.myzubster.com

still returned:

HTTP 200
Content-Type: text/html
Content-Length: 9068

The decisive response header was:

Server: Vercel

DNS inspection then showed the actual architecture:

myzubster.com → Cloudflare → redirect

www.myzubster.com → Vercel

while:

sepolia.myzubster.com → Cloudflare Tunnel → VPS

This explained why changing the VPS static directory could not make the assets appear under www.myzubster.com.

The request was never reaching that VPS service.

Importantly, we did not move the production www hostname away from Vercel just to solve an asset-delivery problem.

11. Dedicated MyZubster media infrastructure created

Instead, we created a dedicated hostname:

media.myzubster.com

and attached it to the existing MyZubster Cloudflare Tunnel.

Its tunnel route is:

media.myzubster.com
→ Cloudflare
→ cloudflared
→ 127.0.0.1:5173
→ MyZubsterWeb/dist

Cloudflare successfully created the DNS route for the existing tunnel.

After restarting the PM2-managed cloudflared process, we performed the final public test.

Result:

HTTP/2 200

Content-Type: image/png

Content-Length: 2162743

Server: cloudflare

That content length exactly matched the original visual file.

This is important because an HTTP 200 alone was not sufficient during debugging: several earlier requests returned 200 while actually serving the SPA HTML fallback.

We verified both MIME type and file size.

12. We now have an independent visual delivery layer

The new architecture is therefore:

GitHub README / MyZubster Knowledge / Marketplace / documentation

↓

media.myzubster.com

↓

Cloudflare Tunnel

↓

MyZubster static infrastructure

↓

versioned visual assets

For example, the Kefir donor workflow is now publicly available at:

https://media.myzubster.com/media/visuals/2026-09-27/kefir-donor-workflow.png

The Sepolia E2E payment visual is available at:

https://media.myzubster.com/media/visuals/2026-09-27/myzubster-sepolia-eth-e2e-payment-flow.png

This gives us a stable asset layer that does not require moving the production website away from Vercel and reduces our dependency on the GitHub repository paths currently affected by the 404 issue.

What comes next

The infrastructure is working, but the interactive knowledge journey is not finished yet.

The next phase is to connect the visual layer to actual MyZubster functionality.

The first target is the Kefir knowledge flow.

We want to connect:

Knowledge

→ Kefir

→ Donors

→ Rimini / Riccione

→ Marketplace listing

→ exchange

→ evidence

→ knowledge

The existing visual “Come funziona MyZubster per i donatori di kefir” can become an interactive entry point rather than just documentation.

The “Donatore di Kefir a Rimini e Riccione” visual can then connect the territorial knowledge layer with the corresponding Marketplace discovery/listing flow.

The goal is not simply to display images.

The goal is to connect documentation, territorial knowledge, Marketplace activity and verifiable evidence into one navigable MyZubster journey.

Remaining work

The main remaining tasks are:

1. Identify and connect the canonical Kefir Knowledge page.
2. Identify the real Marketplace listing/route for Kefir donors in Rimini/Riccione.
3. Add interactive CTAs such as “Find a Kefir Donor”.
4. Connect the Knowledge page to the Marketplace without duplicating source-of-truth data.
5. Replace affected GitHub-hosted visual references with media.myzubster.com where appropriate.
6. Verify the complete browser journey from Knowledge → Marketplace → exchange/evidence.
7. Keep a clear distinction between visual storytelling, application state and independently verifiable evidence.
8. Resolve the separate GitHub 404/support issue without making the public visual infrastructure depend on it.

Why this debugging session mattered

The most useful result was not simply fixing one broken request.

We clarified several architectural boundaries:

• API traffic vs SPA fallback
• Sepolia frontend vs Sepolia backend
• PM2 vs systemd process ownership
• Vercel production hosting vs Cloudflare Tunnel services
• application payment intent vs blockchain transaction
• documentation assets vs runtime infrastructure
• HTTP success codes vs actual response semantics

And we now have a dedicated public media endpoint that can support the next generation of interactive MyZubster documentation.

The next step is to turn the Kefir donor knowledge into a real navigable path between territory, knowledge, Marketplace and evidence.

MyZubster #OpenSource #Web3 #Ethereum #Sepolia #Blockchain #Cloudflare #Vercel #NodeJS #DevOps #Marketplace #KnowledgeGraph #LivingLab #Kefir #Rimini